私はこの分野では初心者なので、ご容赦ください。最近、いくつかのプロジェクトで 1 つの MVC フレームワークを使用していますが、しばらくすると、MVC の「モデル」の有用性に幻滅を感じています。
コントローラーとビューの有用性は理解しています。プレゼンテーションとロジックを分離することが、必ずしも高速化や堅牢化につながるわけではありませんが、将来的にコードをより保守しやすくするために重要であることもわかっています。
そもそもすべてのロジックをコントローラー内に配置する必要がある場合、モデル、特にアクティブ レコードを使用する意味はないと思います。データベースと通信するための堅牢で使いやすい言語はすでにありますよね? それは SQL です。私にとって、モデルがアクティブ レコードのように実装されている場合、その有用性は、アプリを複数のデータベースに適合させるかどうかによって決まります。
私が聞きたいのは、データベースを 1 つだけ使用している場合、なぜモデルや Active Record にこだわる必要があるのかということです。なぜ SQL を使用しないのですか。なぜ余分な複雑さが必要なのでしょうか。データベース クラスと SQL を使用するよりもモデルの方が実際に優れた結果が得られるケース スタディや実例はありますか。
もう一度言いますが、私が無知なようで申し訳ありませんが、モデルがなぜ重要なのか本当にわかりません。ご回答ありがとうございます。
ベストアンサー1
まず、SQL を抽象化するために、モデル レイヤーは必ず何らかの ORM を使用するものと想定しています。これは正しくありません。コントローラー レイヤーとは疎結合だが、特定の DBMS とは密結合したモデル レイヤーを作成すれば、フル機能の ORM の使用を避けることができます。
Hibernate (Java)、NHibernate (.NET)、Doctrine (PHP)、ActiveRecord-Rails (Ruby) など、実際の SQL ステートメントをすべて生成できる ORM ライブラリがいくつかありますが、ORM は不要で、すべての SQL ステートメントを手動で定義したい場合は、これらのライブラリを使用しないでください。
それでも、私見ではこれはないつまり、DB 関連のロジックはすべてコントローラ レイヤー内に配置するということです。これは「ファット コントローラ」アプローチと呼ばれ、多くの場合、肥大化した保守不可能なコードにつながります。単純な CRUD プロジェクトには使用できますが、それ以上の場合は実際の「モデル」の存在が必要になります。
あなたはMVCを気にしているようですね。TDDについても読んでみてください。ある賢人がこう言いました。「レガシーコードはテストのないコードである「自動化されたユニットテストがと同じぐらい重要「実際の」コードを読んでみれば、エンタープライズ アプリケーションに多くのレイヤーが存在する理由と、モデル レイヤーをコントローラーから分離する必要がある理由がわかります。すべて (プレゼンテーション、ビジネス ロジック、データの永続性) を実行しようとするコード ブロックは、簡単にテストできません (デバッグもできません)。
編集
「モデル」というのは少し曖昧な言葉です。見る場所によって、少し意味が異なります。例えば、PHPやRubyのプログラマーは、モデルを「モデル」の同義語としてよく使います。アクティブレコード正確ではありません。他の開発者の中には、「モデル」とは単なる個人情報これも正しくありません。
私はむしろモデルの定義を次のように使います。ウィキペディア:
MVC の中心となるコンポーネントであるモデルは、ユーザー インターフェイスとは関係なく、問題領域の観点からアプリケーションの動作を捉えます。モデルは、アプリケーションのデータ、ロジック、ルールを直接管理します。
モデルはほとんどのMVCアプリケーションにおいて最大かつ最も重要な層です。そのため、通常はドメイン、サービス、データアクセスなどのサブ層に分割されます。モデルは通常露出ドメインを通して、コントローラが呼び出すメソッドが見つかるからです。しかし、データアクセス層も「モデル」に属します。データの永続性そしてビジネスの論理それはそれに属します。