mvc の調査を始めたばかりで、まだ理解できていません。私が収集したものから、3層ソリューションの実装のように見えます。つまり、モデルはDALに対応し、コントローラーはビジネスロジックレイヤーに対応し、ビューはプレゼンテーションレイヤーとして表示されます。
私はここで基地から離れていますか？
4 に答える
8
モデルを単なるデータアクセス層として扱うことには注意が必要です。これは単純化しすぎており、コントローラーレイヤーに多くのコードを配置することになります。そのコードをモデルに追加し、データベースの永続性をモデルの内部コードの一部のみにする方がよいでしょう。私はMVCを次のように考えるのが好きです：
- コントローラ：入力を処理し、インスタンス化するモデルとビューを決定します
- 表示：アプリケーションデータの表示
- モデル：DALを含むがこれに限定されない、アプリケーションの他のすべてのロジック
これは基本的にページコントローラのパターンです。
別の考え方として、WebアプリをコマンドラインアプリやデスクトップGUIアプリなどの別のプラットフォームに移植する必要があるとします。アプリケーションロジックのどの部分を再利用する必要がありますか？アプリを別のプラットフォームに移植すると、入力と出力の両方の実装を変更する必要があるため、コントローラーとビューが変更されます。変更する必要のないコードは、モデルに実装する必要があります。
関心の分離を正しく行った場合、モデル、ビュー、およびコントローラーは最小限に結合され、他にあまり影響を与えずに1つの実装を変更できます。モデルを変更して、コントローラーまたはビューで多くのコードを書き直していることに気付いた場合は、これらのレイヤーを適切に分離していない可能性があります。およびその逆。
マーティンファウラーの貧血ドメインモデルのアンチパターンまたはドメイン駆動設計についてすばやく読んで、他のいくつかの視点を取得してください。
ActiveRecordパターンを非難する人々に応えて書いた2008年の私のブログも参照してください。それはいくつかの良いコメントと議論を得ました。
于 2009-11-18T05:12:42.203 に答える
3
並べ替え。次のようになります。
現在最も一般的に使用されているパターンは次のとおりです。
Database -> DAL -> BLL -> Controller -> View Model -> UI
どこ
DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer
すべてのレイヤーが常に必要なわけではないことに注意してください。たとえば、アプリが十分に小さい場合は、BLL とビュー モデルをオプションにすることができます。
NerdDinner チュートリアルをチェックしてください。 これらの概念はすべて 1 つのリファレンスで説明されています。
于 2009-11-18T04:58:37.460 に答える
1
MVC を初めて使用する場合は、ここにいくつかの優れた説明があります。
于 2009-11-18T04:58:58.750 に答える
0
簡単に言うと、コントローラーがビジネスレイヤーになることができ（そうである必要はない）、ビューがプレゼンテーションレイヤーであると言うときは正しいです。
ただし、モデルはデータを含むオブジェクト（実装によって異なります）ですが、データレイヤーはデータを取得/操作するレイヤーです。
于 2009-11-18T05:09:51.683 に答える