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クエリを使用してjoin
sを実行し、次にselect new MyViewModel(){ ... }
を実行しました。しかし、現在、DALではViewModelが定義されている場所(BLL)にアクセスできません。
つまり、DALで結合を行ってBLLに返すことはできません。 (1つのクエリでの結合の代わりに)DALで個別のクエリを実行する必要があるようですが、BLLはこれらの結果を使用してViewModelを構築します。これは非常に不便ですが、DALをViewModelsに公開する必要があるとは思いません。
このジレンマを解決する方法はありますか?ありがとう。
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;