ASP.NET MVCソリューションのベストストラクチャ

Question

ベストプラクティスのアプローチに従って、私の最後の大規模なMVCプロジェクトを構築しようとしましたが、私が何をしているのかが分かりませんでした。

データ、ビジネス、ウェブ（MVC）プロジェクトがありますが、コントローラにはほとんどのコードが含まれています。データレイヤーはNHibernateを使用していますが、リポジトリの数が多すぎます。ビジネスレイヤーはダンピング地です他の2つのプロジェクトに属していないものについては、それは機能しますが、セットアップがうまくいったと思います。私が不満を抱いている主なものは、太ったコントローラとリポジトリです。

私はまともなサイズに成長する可能性のある新しいプロジェクトを開始しています。そのため、デザインをすぐに手放そうともっと時間を費やしています。もう少し読んだら、私は、aggregate-rootごとにリポジトリを用意して、プレゼンテーション層の各コントローラのビジネスレイヤにサービスを用意しようとしています。

私の最初の希望は、大量のコードがサービスに組み込まれることでした。これは、より小さいリポジトリと組み合わせると、コントローラとデータレイヤーを薄く保つことになりました。これまでのところ、これは起こっていません。

私が読んだことは、ビューモデルがビジネスレイヤから返されるべきではなく、プレゼンテーションレイヤに配置されるべきであることを示唆しています。そのため、サービスレイヤは主にデータレイヤからモデルプレゼンテーション層は、ビューモデルを準備するために必要なものを行います。だから私はまだ太ったコントローラと、薄いビジネスとデータ層を持っています。

私のプレゼンテーションレイヤーでもビジネスレイヤーとデータレイヤーについて知っていますが、この分離のポイントの一部はカップリングを減らすことだと思いましたか？

これは間違っていますか？私は盲目的に私がインターネット上で読んだことに従うのをやめて、単にビジネスレイヤーでビューモデルを準備して、そこにコードの大部分を移動できますか？私は古典的なASPに戻るべきですか？ :)

Answer 1

私がプロジェクト構造を設定するときに使用する主なガイドは、ビジネスロジックレイヤーにいくつかのoperationcontract属性を追加してから、wcfサービスとしてホストできることを保証することです。

これは、ビジネスロジックレイヤーが自分のデータレイヤーを分離し、単純な構造とエンティティを渡すだけでクライアントとやりとりすることを意味します。データレイヤーは完全に隠されています。

だから私の通常の構造は次のようになります。この構造ではそう

Solution 
    Business.Contracts (interfaces for bll layer in here) 
    Business.Logic  (concrete implementations of contracts in here) 
    Business.Entities (Pocos that bll uses) 
    Data.Contracts  (interfaces for dal) 
    Data.Sql   (Concrete Sql implementation of contracts) 
    Common.Enums  (Enums needed by all projects) 
    FrontEnd   (Main mvc app) 

、私のMVCプロジェクトは今までのビジネスの名前空間と共通の名前空間を扱っています。

しかしエンティティとやり取りするとき、私はmvcプロジェクトで独自のモデルを使用してアノテーションやフロントエンド固有の機能を追加する傾向があります。次に、これらのモデルを暗黙的に変換してビジネスエンティティ。

HTH枠組み以下