MVC + 3層; ViewModelsが登場する場所

ASP.NET MVC 4を使用して3層アプリケーションを設計しています。次のリソースを参照として使用しました。

これまでに次のようなデザインがあります。

プレゼンテーション層（PL） （メインMVCプロジェクト、MのMVCは、データアクセス層に移動されました）：

MyProjectName.Main
    Views/
    Controllers/
    ...

ビジネスロジックレイヤー（BLL）：

MyProjectName.BLL
    ViewModels/
    ProjectServices/
    ...

データアクセス層（DAL）：

MyProjectName.DAL
    Models/
    Repositories.EF/
    Repositories.Dapper/
    ...

現在、PLはBLLを参照し、BLLはDALを参照しています。このように、下層は上の層に依存しません。

この設計では、PLはBLLのサービスを呼び出します。PLはビューモデルをBLLに渡すことができ、BLLはビューモデルをPLに戻すことができます。

また、BLLはDALレイヤーを呼び出し、DALレイヤーはモデルをBLLに戻すことができます。BLLは、ビューモデルを作成してPLに返すことができます。

今まで、このパターンは私のために働いていました。ただし、ViewModelsのいくつかがいくつかのエンティティで結合する必要があるという問題に遭遇しました。プレーンMVCアプローチでは、コントローラーでjoinsを実行してからを実行するためにLINQクエリを使用しましたselect new MyViewModel(){ ... }。しかし今、DALでは、ViewModelが定義されている場所（BLL内）にアクセスできません。

これは、DALで参加してBLLに戻すことができないことを意味します。（1つのクエリでの結合の代わりに）DALで個別のクエリを実行する必要があり、BLLはこれらの結果を使用してViewModelを構築します。これは非常に不便ですが、DALをViewModelに公開する必要はないと思います。

このジレンマを解決する方法はありますか？ありがとう。

c# design-patterns asp.net-mvc

— 遊牧民
ソース

MVCのMがデータアクセスレイヤーに移動されたメインMVCプロジェクト

よくある誤解。Mのは、MVCそう主張する多くの例やチュートリアルにもかかわらず、データとは何の関係もありません。

M はViewModelであり、MVCプロジェクトに存在する必要があります。BLLにあるViewModelは、実際にはDataContractsまたはBusinessModelsという名前になります。

コントローラーには、これに匹敵するものがあります。

Get(id):
    dataContract = _service.Get(id);
    viewModel = Map(dataContract);
    return viewModel

あなたのサービスでは、このようなもの：

Get(id):
    dataModel = _dataAccess.Get(id);
    dataContract = Map(dataModel);
    return dataContract;

DataAccessでは、要求されたオブジェクトに応じて適切な結合を実行します。ただし、必要に応じてDataAccessにカスタムメソッドを追加するのはもちろん自由なので、サービスはこれらのメソッドを呼び出すことができます。

GetWithBars():
    dataModels = _repository.Query("select from foos join bars");
    return dataModels;

— CodeCaster
ソース