厳密なMVCフレームワークでORMを使用する

Question

私は、ColdFusion ORMの初心者です。私は、助けを求めていたと思います。

私はかなり標準的で厳格なMVCアーキテクチャを使用するフレームワークに取り組んでいます。このフレームワークには、コントローラとモデルの間に位置する「サービス層」もあります。サービス層は、すべてのビジネスロジックと検証を処理しています。

標準CRUD処理は次のように進む：

ユーザは、ビューを介してフォームを送信 - >ビューコントローラに提出 - コントローラが処理のためにサービスレイヤに送信> - >サービス層を実行することができます任意の種類のビジネスロジックと要求に対する検証 - >サービス層がデータをモデルに送信 - >モデルがEntityNew（）とEntitySave（） - を使用してトランザクションを実行するサービス層にIDを返す応答 - >サービス層はロジックを適用してユーザにメッセージを作成する - 応答層に応答メッセージを送るよりサービス層 - >コントローラはそれをビューに送る - >ビューがユーザーに表示されます。

このプロセスはうまくいき、私は役割の分離に満足しています。これは、すべてのロジックをビュー、コントローラ、およびモデルから離れた状態に保ち、サービスレイヤで分離します。

私の質問は、ユーザー名がバリデーションのためにユニークであるかどうかをチェックするなど、サービスレイヤのデータベースと通信する必要があるときです。今はサービスレイヤでEntityLoad（）を実行しています。これは技術的にモデルレイヤーを回り、ORMを介してデータベースと直接的にやりとりするようです。これはMVCフレームワークを壊すと考えられるでしょうか？

もう1つのことは、ドロップダウンのデータを取得するためにビュー内でEntityLoad（）を実行しているときに、データベースからのデータをビューにドロップダウンする必要があるかどうかです。この場合も、ORMを介してデータベースと通信するために、技術的にモデルを取り巻いています。

私は厳密なMVCフレームワークでORMを使用するベストプラクティスについて混乱していると思います。モデルファイルにデータベースとのやりとりごとに別々のメソッドを用意し、ビューまたはサービスレイヤーでモデル内のメソッドと通信させるだけですか？そんなことを考えようとすると、すべての組織が失われているようだ。

これを念頭に置いています。

この件に関するお手伝いをいただければ幸いです。

ありがとうございます。

Answer 1

私の意見では、ORMをサービス層から直接使用するのは問題ありません。おそらく、抽象化する理由はそれほどありません。 ORM機能をゲートウェイまたはDAOと考えてください。あなたが本当に望むなら、それらの機能をゲートウェイやDAOに入れることができます。

ORMを直接使用するのは間違いです。それをしないでください。それを処理するには、より良い方法がいくつかあります。

• は、あなたが（モデルに話す）コントローラからページを構築するための他のデータと返された必要なデータを持っています。

• ビューからサービス・レイヤー（Ajaxy）へのリモート・コールを行い、データを取得します。

これを処理する方法は他にもあります（おそらく？）。しかし結論は、あなたのビューはモデルレイヤーと話してはならないということです。