web-dev-qa-db-ja.com

MVC + 3層; ViewModelsが関係するのはどこですか?

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

これまでに以下のデザインを持っています。

プレゼンテーションレイヤー(PL)(メインMVCプロジェクト、ここで[〜#〜] m [〜#〜]of[〜#〜] 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に返すことができます。

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

つまり、DALで結合を行ってBLLに返すことはできません。 (1つのクエリでの結合の代わりに)DALで個別のクエリを実行する必要があるようですが、BLLはこれらの結果を使用してViewModelを構築します。これは非常に不便ですが、DALをViewModelsに公開する必要があるとは思いません。

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

11
nomad

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

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

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;
18
CodeCaster