3

私は MVC に非常に慣れていないことを認めることから、この質問を始めます。デザイン パターンは大まかに理解できますが、ASP.NET MVC を調べている今、アーキテクチャの一部が私の先入観に挑戦しています。学ぶことは良いことです。

私は最近、ASP.NET MVC を作成した会社の人々によって作成された学習ツールとして、つまり ASP.NET MVC の表向きのリファレンス アプリケーションとしてOxiteを使用しています。

しかし今日、Rob Conery による Oxiteに関する次のようなブログ記事を見ました。

Oxite チームが決定したことの 1 つは、コントローラーとビューを別のプロジェクトに分離することでした。これは、私が推測できるのは、ビュー ロジックからビジネス ロジックを分離することだけです。コントローラーはアプリケーション フローを処理するためのものであり、必ずしもビジネス ロジックとは限らないため、これは混乱を招く可能性があります。

これは私をループに陥れました。この分離は MVC の信条であり、したがって Oxite 開発者による間違いですか、それとも Rob の意見ですか? ビジネス ロジックがモデルに属している場合、Oxite チームはなぜそれをコントローラーに組み込んだのでしょうか? コントローラーにない場合、ビジネスロジックであるアクションを実行するにはどうすればよいですか?

それに加えて、Rob のようなコメントを考慮して、Oxite を学習ベンチマークとして使用するのは間違いですか?

4

2 に答える 2

2

ビジネス ロジックは、ビジネス レイヤーに入ります。コントローラーは、ビジネス レイヤーを使用して、ビューがレンダリングするモデルを作成します。良い例は、Rob Conery が作成した MVC Storefront アプリケーションです。Oxite は、明らかに MVC フレームワークを十分に活用していないため、現在多くの悪い報道を受けています。

コントローラーとは別のビジネス層が必要な理由は、複数のコントローラーまたは複数のアプリケーションでビジネス層を再利用したい場合があるからです。この例としては、データを表示するための通常のユーザー機能と、データを更新および追加するための管理機能があります。どちらの場合も同じ BL コンポーネントを使用できますが、データにレンダリングするコントローラーとビューは異なります。モデル オブジェクトは同じです。

于 2008-12-16T16:24:39.123 に答える
1

エンティティ、集計、リポジトリ、およびサービスを使用して、ビジネス レイヤー (つまり、モデル) を実装できます。サービスはリポジトリを呼び出し、エンティティの形式で DAL からデータをプルします。

これは、DLL にすぎない単一の個​​別のプロジェクトで設定できます。

次に、実際にはプレゼンテーション レイヤーである MVC アプリを作成し、ビジネス レイヤー プロジェクトを利用させます。コントローラーはサービスと連携し、これらのサービスが生成するデータを ViewData に送り込み、ビューに送り込みます。

コントローラーは、フォーム、クエリ文字列、Cookie、セッションなどからのユーザー入力に基づいて、表示するビューなどのルーティングの問題のみを処理する必要があります。

「MVC 純粋主義者」コミュニティから、MVC の良い例として使用されている Oxite の有効性について大騒ぎがありました。肝心なのは、ビジネス ロジックをコントローラーに含めるべきではないということです。これは、今後数か月にわたって Oxite がリファクタリングされるときにわかると思います。

于 2008-12-17T15:54:17.280 に答える