MVC + 3 ярус; де ViewModels вступає в гру?

Я розробляю трирівневу програму за допомогою ASP.NET MVC 4. Я використовував наступні ресурси як орієнтир.

На сьогоднішній день у мене є наступний проект.

Рівень представлення (PL) (основний проект MVC, де М з 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 в контролері я використовував запит LINQ, щоб зробити joins, а потім select new MyViewModel(){ ... }. Але тепер у DAL у мене немає доступу до того, де визначено ViewModels (в BLL).

Це означає, що я не можу приєднуватися до DAL і повертати його до BLL. Здається, я повинен робити окремі запити в DAL (замість об'єднання в один запит), а потім BLL використовує результат цих даних для створення ViewModel. Це дуже незручно, але я не думаю, що я повинен виставляти DAL на ViewModels.

Будь-які ідеї, як я можу вирішити цю дилему? Дякую.

c# design-patterns asp.net-mvc

— кочівник
джерело

основний проект MVC, де M MVC переміщено до рівня доступу до даних

Поширене неправильне уявлення. MЗ MVCне має нічого спільного з даними, незважаючи на численні приклади і навчальні програми, які стверджують , що так.

M є вашим ViewModel і має проживати у вашому проекті MVC. ViewModels, які є у вашому BLL, насправді мають назвати 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
джерело