ThinkPHP-3.1、thinkphp-3.1
基本:
1. 基本概念
ランプ
LAMP は、Linux、Apache、MySQL、PHP をベースにしたオープンソースの Web 開発プラットフォームです。この用語はヨーロッパに由来しており、ヨーロッパではこれらのプログラムが標準の開発環境として一般的に使用されていました。名前は各プログラムの頭文字に由来しています。各プログラムは、その所有権においてオープン ソース標準に準拠しています。Linux はオープン システムであり、Apache は、Web ベースの管理用の追加ツールを備えたリレーショナル データベースです。他の言語の優れた機能の多くを利用して、Web 開発をより効率的にします。 Windows オペレーティング システム上の Linux 環境でこれらのツールを使用する開発者は、WAMP を使用して呼び出されます。
これらのオープン ソース プログラム自体は、他のいくつかのプログラムと連携して動作するように特別に設計されているわけではありませんが、これらはすべて影響力のあるオープン ソース ソフトウェアであり、多くの共通の特性を共有しているため、これらのコンポーネントは一緒に使用されることがよくあります。過去数年間にわたって、これらのコンポーネントの互換性は向上し続けており、それらを組み合わせて使用することがより一般的になりました。そして、さまざまなコンポーネント間の連携を改善するために、特定の拡張機能を作成しました。現在、これらの製品は、ほとんどすべての Linux ディストリビューションにデフォルトで含まれています。 Linux オペレーティング システム、Apache サーバー、MySQL データベース、Perl、PHP、または Python 言語、これらの製品が連携して強力な Web アプリケーション プラットフォームを形成します。
オープンソーストレンドの活発な発展に伴い、オープンソースLAMPはJ2EEおよび.Net商用ソフトウェアと三位一体のトレンドを形成しており、ソフトウェア開発プロジェクトはソフトウェアへの投資コストが低いため、IT全体の注目を集めています。コミュニティ。 Web サイトのトラフィックに関しては、LAMP が最も強力な Web サイト ソリューションです。
おっと
オブジェクト指向プログラミング (OOP、オブジェクト指向プログラミング) は、コンピューター プログラミング アーキテクチャです。 OOP の基本原理は、コンピューター プログラムがサブルーチンとして機能する単一のユニットまたはオブジェクトで構成されるということです。 OOP は、再利用性、柔軟性、拡張性というソフトウェア エンジニアリングの 3 つの主な目標を達成します。全体的な操作を実現するために、各オブジェクトは情報を受信し、データを処理し、他のオブジェクトに情報を送信できます。 OOP には主に次の概念とコンポーネントがあります:
コンポーネント - 実行中のコンピューター プログラム内でデータと機能が一緒に形成される単位。コンポーネントは、OOP コンピューター プログラムのモジュールと構造の基礎です。
抽象性 - プログラムには、処理される情報の特定の側面を無視する機能、つまり、情報の主要な側面に焦点を当てる機能があります。
カプセル化 - 情報カプセル化とも呼ばれます。コンポーネントが他のコンポーネントの内部状態を予期しない方法で変更しないことを保証します。内部状態変更メソッドを提供するコンポーネントのみが内部状態にアクセスできます。各タイプのコンポーネントは、他のコンポーネントと通信するためのインターフェイスを提供し、他のコンポーネントが呼び出すメソッドを指定します。
ポリモーフィズム - コンポーネント参照とクラス セットには、他の多くの異なるタイプのコンポーネントが含まれており、参照されたコンポーネントによって生成される結果は、実際の呼び出しタイプによって異なります。
継承 - 既存のコンポーネントに基づいてサブクラス化されたコンポーネントを作成できるようにし、ポリモーフィズムとカプセル化を統合および強化します。通常、クラスはコンポーネントをグループ化するために使用されますが、新しいクラスを既存のクラスの拡張として定義することもできるため、クラスをツリー構造またはネットワーク構造に編成して、アクションの多用途性を反映できます。
コンポーネントベースのプログラミングは、抽象化、カプセル化、再利用性、使いやすさなどの理由から、スクリプト言語で特に人気があります。
MVC
MVC は、アプリケーションの入力、処理、出力の分離を強制する設計パターンです。 MVC を使用するアプリケーションは、モデル (M)、ビュー (V)、およびコントローラー (C) の 3 つのコア コンポーネントに分割されており、それぞれが独自のタスクを処理します。
View: View は、ユーザーが表示して操作するインターフェイスです。旧式の Web アプリケーションの場合、ビューは HTML 要素で構成されるインターフェイスです。新しいスタイルの Web アプリケーションでも、HTML は依然としてビュー内で重要な役割を果たしていますが、Adobe Flash や一部のマークアップ言語など、いくつかの新しいテクノロジが際限なく登場しています。 XHTML、XML/XSL、WML などの Web サービスアプリケーションのインターフェイスをどのように扱うかは、ますます困難になってきています。 MVC の大きな利点の 1 つは、アプリケーションのさまざまなビューを処理できることです。データがオンラインで保存されているか、従業員のリストで保存されているかにかかわらず、ビューでは実際の処理は発生せず、データを出力してユーザーが操作できるようにする手段としてのみ機能します。
モデル: モデルは企業データとビジネス ルールを表します。 MVC の 3 つのコンポーネントの中で、モデルには最も多くの処理タスクがあります。たとえば、EJB や ColdFusion コンポーネントなどのコンポーネント オブジェクトを使用してデータベースを処理する場合があります。モデルによって返されるデータはニュートラルです。これは、モデルがデータ形式とは何の関係もないことを意味するため、モデルは複数のビューにデータを提供できます。モデルに適用されるコードは 1 回記述するだけで済み、複数のビューで再利用できるため、コードの重複が削減されます。
コントローラー: コントローラーはユーザー入力を受け入れ、モデルとビューを呼び出してユーザーのニーズを満たします。そのため、Web ページ内のハイパーリンクがクリックされて HTML フォームが送信された場合、コントローラー自体は何も出力したり、処理を実行したりしません。リクエストを受信し、リクエストを処理するためにどのモデル コンポーネントを呼び出すかを決定し、モデル処理によって返されたデータを表示するためにどのビューを使用するかを決定するだけです。
次に、MVC の処理プロセスを要約します。まず、コントローラーはユーザーのリクエストを受け取り、処理のためにどのモデルを呼び出すかを決定します。次に、モデルはビジネス ロジックを使用してユーザーのリクエストを処理し、データを返します。データは、対応するビューとともに返され、プレゼンテーション層を通じてユーザーに表示されます。
ORM
オブジェクト/リレーション マッピング (略して ORM) は、オブジェクト指向ソフトウェア開発手法の開発とともに生まれました。オブジェクト指向開発手法は、今日のエンタープライズレベルのアプリケーション開発環境における主流の開発手法であり、リレーショナルデータベースは、エンタープライズレベルのアプリケーション環境でデータを永続的に保存する主流のデータストレージシステムです。オブジェクトとリレーショナル データは、ビジネス エンティティの 2 つの表現形式です。ビジネス エンティティは、メモリ内ではオブジェクトとして表され、データベース内ではリレーショナル データとして表されます。メモリ内のオブジェクト間には関連付けや継承関係がありますが、データベースではリレーショナル データは多対多の関連付けや継承関係を直接表現できません。したがって、オブジェクト リレーショナル マッピング (ORM) システムは一般にミドルウェアの形式で存在し、主にプログラム オブジェクトからリレーショナル データベース データへのマッピングを実装します。
オブジェクト指向はソフトウェア工学の基本原理 (結合、集約、カプセル化など) に基づいて開発されますが、リレーショナル データベースは数学理論に基づいて開発されます。この 2 つの理論には大きな違いがあります。この不一致現象を解決するために、オブジェクト リレーショナル マッピング技術が登場しました。
AOP
AOP(Aspect-Oriented Programming、アスペクト指向プログラミング)は、OOP(Object-Oriented Programming、オブジェクト指向プログラミング)を補完・改良したものと言えます。 OOP では、カプセル化、継承、ポリモーフィズムなどの概念を導入して、オブジェクト階層を確立し、一般的な動作のコレクションをシミュレートします。分散オブジェクトにパブリックな動作を導入する必要がある場合、OOP は無力です。つまり、OOP では上から下への関係を定義できますが、左から右への関係の定義には適していません。例えばロギング機能。ロギング コードは、すべてのオブジェクト階層にわたって水平に分散される傾向があり、分散先のオブジェクトのコア機能とは何の関係もありません。セキュリティ、例外処理、透過的な永続性など、他のタイプのコードにも同じことが当てはまります。この種の無関係なコードが随所に散在することは、OOP 設計では横断的コードと呼ばれ、大量のコードの重複につながり、さまざまなモジュールの再利用に役立ちません。 AOP テクノロジーはその逆で、「クロスカッティング」と呼ばれるテクノロジーを使用して、カプセル化されたオブジェクトの内部を解剖し、複数のクラスに影響を与えるパブリックな動作を再利用可能なモジュールにカプセル化し、それを「アスペクト」と呼びます。側面。いわゆる「アスペクト」とは、簡単に言えば、システム内のコードの重複を減らし、結合を減らすために、ビジネスとは関係がないが、ビジネス モジュールによって共同で呼び出されるロジックや責任をカプセル化することです。モジュール間の信頼性を高め、将来の信頼性を高めます。 AOP は水平関係を表します。「オブジェクト」がオブジェクトのプロパティと動作をカプセル化する中空の円筒である場合、アスペクト指向のプログラミング手法は、これらの中空の円筒を細かく切り分けるようなものです。中の情報。カットされた断面はいわゆる「アスペクト」です。そして、これらの切断部分を驚異的な技術で跡形もなく復元しました。
「横断的」テクノロジーを使用して、AOP はソフトウェア システムを 2 つの部分、つまり中核的な関心事と横断的な関心事に分割します。業務処理のメインプロセスが中心的な関心事であり、それとあまり関係のない部分が横断的な関心事です。横断的な懸念事項の特徴の 1 つは、それらが中核的な懸念事項の複数の場所で発生することが多いですが、基本的にはどこでも同様であるということです。権限認証、ロギング、トランザクション処理など。 Aop の役割は、システム内のさまざまな懸念事項を分離し、中核的な懸念事項と横断的な懸念事項を分離することです。アバナードのシニア ソリューション アーキテクトであるアダム マギー氏が述べたように、AOP の中心的な考え方は、「アプリケーション内のビジネス ロジックを、それをサポートする共通サービスから分離する」ことです。
カード
CURDとはデータベーステクノロジーの略称で、一般的なプロジェクト開発における各種パラメータの基本的な機能を指します。これは、作成、更新、読み取り、および削除の操作を表します。 CURD は、データを処理するための基本的なアトミック操作を定義します。 CURD が技術的に難しいレベルにまで引き上げられている理由は、複数のデータベース システムで CURD 操作を含む集計関連アクティビティを完了するパフォーマンスが、データ関係の変化に応じて大きく異なる可能性があるためです。
CURD は、特定のアプリケーションで作成、更新、読み取り、および削除メソッドを必ずしも使用するわけではありませんが、それらが実行する機能は同じです。たとえば、ThinkPHP は、add、save、select、および delete メソッドを使用して、モデルの CURD 操作を表します。
アクティブレコード
アクティブ レコード (中国語名: アクティブ レコード) は、リレーショナル データベースのテーブルに対応するモデル クラスと、テーブル内のレコードの行に対応するモデル クラスのインスタンスによって特徴付けられるドメイン モデル パターンです。 Active Record と Row Gateway はよく似ていますが、前者はドメイン モデル、後者はデータ ソース モデルです。リレーショナル データベースは、多くの場合、外部キーを通じてエンティティの関係を表現します。また、Active Record は、この関係をデータ ソース レベルでのオブジェクトの関連付けと集計にマップします。 Active Record は、非常に単純なドメイン要件、特にドメイン モデルとデータベース モデルが非常に似ている場合に適しています。より複雑なドメイン モデル構造 (継承と戦略を使用したドメイン モデルなど) が発生した場合は、多くの場合、データ ソースを分離し、それをデータ マッパーと組み合わせるドメイン モデルを使用する必要があります。
Active Recordドライバーフレームワークは一般的にORMフレームワークの機能を備えていますが、Row Gatewayとの違いと同様に、Active Recordは単純なORMではありません。 Rails によって最初に提案されたこのモデルは、テーブルがレコードにマップされ、レコードがオブジェクトにマップされ、フィールドがオブジェクトのプロパティにマップされるという標準 ORM モデルに従っています。次の命名規則と構成規則を使用すると、モデルの操作を大幅に迅速に実現でき、簡潔で理解しやすくなります。
単一入口
単一エントリは、通常、プロジェクトまたはアプリケーションに統合された (ただし、必ずしも一意である必要はない) エントリ ファイルがあることを意味します。つまり、プロジェクトのすべての機能操作がこのエントリ ファイルを通じて実行され、多くの場合、エントリ ファイルが最初のステップで実行されます。
入り口が 1 つであることの利点は、同じ入り口にはさまざまな操作に対して同じルールが適用されることが多いため、プロジェクト全体が比較的標準化されていることです。また、入口が単一であることのメリットとして、傍受が便利なため制御が柔軟になり、一部の権限制御やユーザーログインなどの判断や操作を統一的に処理できることも挙げられます。
すべての Web サイトが 1 つのエントリ ファイルを通じてアクセスされるのではないかと心配する人もいるかもしれませんが、実際、これは根拠のない考えです。
2. ディレクトリ構造
| ディレクトリ/ファイル |
説明 |
| ThinkPHP.php |
フレームワークエントリーファイル |
| 共通 |
フレームワークの公開ファイルディレクトリ |
| 会議 |
フレームワーク設定ファイルのディレクトリ |
| ラング |
フレームワークシステム言語ディレクトリ |
| リブ |
システムコア基本クラスライブラリディレクトリ |
| Tpl |
システムテンプレートディレクトリ |
| 延長 |
フレームワーク拡張ディレクトリ (拡張ディレクトリの詳細については、後述の拡張機能の章を参照してください) |
注: コア バージョンをダウンロードすると、ThinkPHP 自体は拡張機能に依存しないため、Extend ディレクトリが空になる可能性があります。
3. 命名規則
ThinkPHP を使用して開発する場合は、次の命名規則に従うようにしてください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
