web-dev-qa-db-ja.com

ASP.NETMVCソリューションに最適な構造

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

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

私はまともなサイズに成長するかもしれない新しいプロジェクトを始めているので、私は自分のデザインを真っ先に手に入れるためにもう少し時間を費やしています。もう少し読んだので、aggregate-rootごとにリポジトリを作成し、プレゼンテーション層の各コントローラーのビジネスレイヤーにサービスを作成しようとしています。

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

私が読んだすべてのことは、ビューモデルはビジネスレイヤーから返されるべきではなく、プレゼンテーションレイヤーに入力されるべきであることを示唆しているので、現時点では、サービスレイヤーは主にデータレイヤーからプレゼンテーションレイヤーにモデルを渡します。ビューモデルを準備するために必要なことを行います。だから私はまだファットコントローラーに加えて、薄いビジネスとデータレイヤーを持っています。

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

私はこれをすべて間違っていますか？インターネットで読んだ内容を盲目的に追跡するのをやめ、ビジネスレイヤーでビューモデルを準備して、コードの大部分をそこに移動できるようにする必要がありますか？従来のASPに戻る必要がありますか？ :)

asp.net-mvc-4structuren-tier-architecture
15
littlecharva

プロジェクト構造を設定するときに使用する主なガイドは、いくつかの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

12
Slicksim