14

単一のプロジェクトソリューション内で、多数のコントローラーがある場合にAreasを導入すると、分離が改善され、モジュールをソリューションに簡単にコピーしたり、ソリューションからコピーしたりできるようになります。ただし、大規模なエンタープライズソリューションでは、代わりにロジックを個別のプロジェクトに分割することをお勧めします。

したがって、個別のUI、コントローラー、SOA、モデル、およびリポジトリプロジェクトがあります。このシナリオでは、エリアはもはや意味がありません。さらに、コントローラーを一意に保つ場合はURLのエリアを省略できますが、そうではない場合でも、URLに追加のトップレベルが追加されます。少し臭い？

おそらく、エリアは中程度の複雑さのサイトに適しているか、モジュールコードを1つの場所に保持して、他のサイトにコピーしたり削除したりできるようにする場合に適しています。

4

2 に答える 2

13

それが正しい質問かどうかはわかりません。 エリアは小さなプロジェクトにとってはやり過ぎかもしれませんが、クラスを整理するのに役立つエリアを使用しない、自明ではない大規模なプロジェクトを想像するのは難しいです。

私は企業にMVCAreasを使用しており、いくつかの点が気に入っています。

  1. 通常、ユーザーは特定のドメイン内の機能（検索、チェックアウトなど）に取り組んでいます。エリア名がビジネスドメインに対応している場合、 MVCエリアは、関連するクラスを簡単に見つけることができるため、機能の実装にかかる時間を短縮するのに役立ちます。
  2. MVCルーティングにより、URLの構造を柔軟に設定できます。以前はActionControllerの「パターン」を使用していましたが、公開されていないURLの場合は、簡単にするためにAreaのデフォルトルートを完全に採用しました。
  3. エリアは、スタイリングの明確な利点を提供し、さらに重要なことに、サイトセクションレベルでの動作をカプセル化します。各領域には独自のWeb構成があり、ベースビューページを制御したり、マネージハンドラーを追加したりできます。

複数のクライアントが共通のビジネス機能にアクセスできる環境で、サービスが完全に別々のプロジェクト/ソリューションにあり、リポジトリを介してデータアクセスを抽象化する必要があることは間違いありません。

しかし、MVCエリアは、Webプロジェクトが成長するにつれて、UI /ルーティングの混乱に何らかの秩序を提供するのに優れています。これは、コンテキストに関係なく、私にとって非常に貴重です。

于 2012-01-30T17:32:21.267 に答える
1

まず、答える前に、これは私の意見であり、主にモデルに関するものであることに注意してください。

私の見方では、エリアは非常に悪である可能性があります。多くのエリアがある場合、ソリューションエクスプローラーは迷路になり、何かを見つけるのが非常に難しくなる可能性があります。

ソリューション内に新しいライブラリプロジェクトを作成し、そこにロジックを配置することをお勧めします。

最良の利点（そして、探しているものをはるかに簡単に見つけることができるということではありません）は、アプリケーションがはるかにモジュール化されることです。ライブラリを作成し、ASP.NET MVCアプリケーションでその参照を指定すると、簡単に間違いを犯したり、ロジックにUIを組み込んだりすることはできません。

于 2013-02-07T23:55:55.487 に答える