MVC + 3 tier; di mana ViewModels berperan?

Saya merancang aplikasi 3-tier menggunakan ASP.NET MVC 4. Saya menggunakan sumber daya berikut sebagai referensi.

• Proyek Kode: MVC + N-tier + Kerangka Entitas
• Memisahkan akses data dalam ASP.NET MVC

Saya memiliki desingn berikut sejauh ini.

Presentation Layer (PL) (proyek MVC utama, di mana M dari MVC dipindahkan ke Data Access Layer):

MyProjectName.Main
    Views/
    Controllers/
    ...

Lapisan Logika Bisnis (BLL) :

MyProjectName.BLL
    ViewModels/
    ProjectServices/
    ...

Lapisan Akses Data (DAL) :

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

Sekarang, referensi PL BLL dan referensi BLL DAL. Dengan cara ini lapisan bawah tidak tergantung pada yang di atasnya.

Dalam desain ini PL menggunakan layanan BLL. PL dapat meneruskan Model Tampilan ke BLL dan BLL dapat meneruskan Model Tampilan kembali ke PL.

Juga, BLL memanggil lapisan DAL dan lapisan DAL dapat mengembalikan Model kembali ke BLL. BLL pada gilirannya membangun Model Tampilan dan mengembalikannya ke PL.

Sampai sekarang pola ini bekerja untuk saya. Namun, saya mengalami masalah di mana beberapa ViewModels saya memerlukan penggabungan pada beberapa entitas. Dalam pendekatan MVC biasa, di controller saya menggunakan query LINQ untuk melakukan joindan kemudian select new MyViewModel(){ ... }. Tapi sekarang, di DAL saya tidak memiliki akses ke tempat ViewModels didefinisikan (di BLL).

Ini berarti saya tidak bisa bergabung dengan DAL dan mengembalikannya ke BLL. Tampaknya saya harus melakukan kueri terpisah di DAL (alih-alih bergabung dalam satu permintaan) dan BLL kemudian akan menggunakan hasil ini untuk membangun ViewModel. Ini sangat merepotkan, tapi saya tidak berpikir saya harus mengekspos DAL ke ViewModels.

Adakah ide bagaimana saya bisa menyelesaikan dilema ini? Terima kasih.

proyek MVC utama, di mana MVC dipindahkan ke Lapisan Akses Data

Kesalahpahaman umum. The Mdari MVCtidak ada hubungannya dengan data, meskipun banyak contoh dan tutorial yang mengklaim begitu.

M adalah ViewModel Anda dan harus berada di proyek MVC Anda. ViewModels yang Anda miliki di BLL Anda sebenarnya akan dinamai DataContracts atau BusinessModels.

Di controller Anda, Anda memiliki sesuatu yang sebanding dengan ini:

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

Dalam layanan Anda, sesuatu seperti ini:

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

Dan di DataAccess, Anda melakukan gabungan yang tepat sesuai dengan objek yang diminta. Namun Anda tentu saja bebas untuk menambahkan metode khusus ke DataAccess Anda saat diperlukan, sehingga layanan Anda dapat memanggil metode-metode itu:

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