物事を機能させることが唯一の要件である場合、すべての制御ログインと DB 処理ロジックをビューに配置することができ、機能します。ただし、これは再利用可能な設計の正しいアプローチではありません。
実際の設計に関する質問をする前に、モデルに関する責任の分離に関する現在の理解を以下に示します。
- データベース関連のすべてのコードは、データベース関連のロジックも含めて、モデルに含める必要があります。
- たとえば「my_tab」というテーブルの場合、propel は 4 つのクラスを生成します。そのうち、「MyTab.php」と「MyTabPeer.php」の 2 つのクラスのみを編集する必要があります。
- MyTabPeer.php には、データのフェッチのみが必要です。
- データを取得するために必要なロジックは、「MyTab.php」に入れる必要があります。
これは簡単で、正しいことを願っています。そうでない場合は、修正してください。
今、私には特別な条件があります。a、b、c、dと言う4つのテーブルがあります。そのために、propel は 8 つの編集可能なクラスを生成しました (base*.php を除く)
A.php APeer.php B.php BPeer.php
C.php CPeer.php D.php DPeer.php
私のアプリケーションの 1 ページには、Mailbox (たとえば) が表示されます。メールボックスはデータベース内のテーブルではありませんが、多くの計算/条件とともに、上記の 4 つのテーブル間の複雑な結合クエリからデータを取得します。
そのクエリを生成し、そこからデータを取得して表示しました。メールボックスは期待どおりに動作しています。ただし、コントローラー(アクションクラス)で実行しましたが、これは適切な場所ではないことがわかっています。
私の質問は、そのコードをどこに置くべきですか? 可能なオプション:
- コントローラーは、DB ロジック/フェッチに適した場所ではないと思います。
- 私は8つのモデルを分類しましたが、データはそれらのいずれにも属さず、それらすべての組み合わせとして属しています。
- 別のヘルパー/ライブラリですが、そのコードをサイトの独自のページとして再利用することは決してありません.
- どこか他の?
私が間違っているかどうかを提案してください。データを取得しているので、モデルに入れる必要があると思います。A はプライマリ テーブルなので、おそらく A.php と APeer.php にコードを配置する必要があります。それが正しい場合、次の質問は、A.php に何を入れるべきか、APeer.php に何を入れるべきかということです。私は次の操作を行いました:
- どの列を選択する必要があるかを決定するロジック。
- メールボックスと同じように、受信/送信メッセージを表示できます。コントローラーは何を表示するかを指示しますが、条件を設定するための db ロジックがいくつかあります。
- 次に、複雑な Join クエリから実際にデータを取得します。
- 返されるデータにはすべての行が含まれますが、条件付きでいくつかの行をマージする必要がある場合があります。
私の理解では、ポイント 3 は APeer.php に入り、A.php に残ります。私の理解は正しいですか?