3

Codeigniter と Doctrine を使用して php プロジェクトを作成する必要があります。私は j2ee をよく使っていましたが、php プロジェクトで同じプロジェクト構造を使用したいと考えています。

だからここに私が考えていることがあります：

  1. コントローラ例(UserController)
  2. サービス別名モデル インターフェース (UserService)
  3. サービスの実装例 (UserServiceImpl は UserService を実装します)
  4. Dao インターフェイス (UserDao)
  5. Dao インターフェイスの実装例 (DoctrineUserDao)
  6. 教義の実体
  7. ビュー

サービス用の php プロジェクト インターフェイスに実装されているのを見たことがなく、dao のデザイン パターンが常に欠落しています。インターフェイスと DAO は php mvc プロジェクトで冗長ですか?

もう 1 つの質問: 私が知る限り、Codeigniter は次の構文を使用してモデルをロードします: $this->load->model('UserServiceImpl'); 私の意見では、これは一種の不自由です。名前空間でオートローダーを使用することを好みますが、これは悪いことですか?

4

1 に答える 1

1

CodeIgniter を使用していくつかの小さなシステムを設計しましたが、現在は大きなシステムを設計/構築しています。私は常に同じ構造 (ここで説明するもの) に従いましたが、これまでのところ非常にうまく機能しています。私の現在のプロジェクトでは、Doctrine を ORM として使用しようとしましたが、最終的にプロジェクトから除外することにしました。

（レイヤーには少し異なる用語を使用する場合がありますが、可能な限り、用語と並行して配置しようとしました。）

私が使用する構造は次のとおりです。

  1. コントローラー (例: /application/controllers/UserController.php)
  2. Data Mapper (ORM) レイヤー (例: /models/tables/UserTable.php)
  3. ドメイン オブジェクト層 (例: /models/data_models/User.php)
  4. レイアウト (例: /models/layouts/default.php)
  5. テンプレート (ビュー) (例: /application/templates/user/view-profile.php)

責任:

  • (2) Data Mapper レイヤーには、すべての SQL とすべての Doctrine EntityManager の使用法が含まれています。ドメイン オブジェクトを格納および取得します。
  • (3) ドメイン オブジェクトはエンティティを表します (Docblock Annotations 形式を使用して、Doctrine のコメントに記述されたエンティティ メタデータを使用)。
  • (1) コントローラーは、ORM レイヤーを呼び出すロジックのみを実行します。おそらく、データまたは計算の再構築を実行します。
  • (4) レイアウト レイヤーは、ページの準静的なフレームをより動的なコンテンツから分離するのに大いに役立ちます。CodeIgniter とレイアウトを参照してください。あなたがアイデアが好きなら。
  • (5) テンプレートは基本的に、いくつかの PHP スニペットを含む HTML です。

クラスを含むすべてのファイルには、ファイル名と同じ名前のファイルごとに1つのクラスが含まれています（http://www.php-fig.org/psr/0/に従って）が、難しいと思うため、名前空間を使用しませんそれらを使用しない CodeIgniter で動作するようにします。

特に小規模または中規模のプロジェクトで作業していて、パフォーマンスが重要でない場合は、モデルをオートローダーにロードできます。このような場合、私は常にすべてのモデルをオートローダーでロードします。ただし、より大きなプロジェクトでは、広く使用されているモデルをオートローダーにロードし、より具体的なモデルをコントローラー コンストラクターにロードしたり、より具体的なモデルをアクションにロードしたりすることをお勧めします。

于 2013-10-17T09:16:28.920 に答える