Советы по разработке шаблонов - отделение ViewModels от моделей домена

Question

Мне нужно отделить ViewModel в моем проекте MVC от моих бизнес-моделей (уровень доступа к данным), который находится в отдельной библиотеке.

Предположим, у меня есть классы уровня доступа к базе данных в отдельной библиотеке.Наш основной проект (MVC) ничего не знает об этих классах, и они общаются друг с другом через интерфейс.Достаточно просто использовать IOC и разрешить внедрение зависимостей с помощью Ninject или чего-то еще, верно?

Теперь DataAccessLayer содержит класс с именем Car со свойствами Engine и Wheel.В моем проекте MVC (который ничего не знает о DataAccessLayer и его классах) мне нужно использовать некоторые объекты Car.Итак, у меня есть другой класс Car (это просто чистая ViewModel), и он имеет те же свойства - Engine и Wheel (конечно, в реальном приложении будут некоторые различия между моделью и viewmodel, для простоты давайте проигнорируем это)

Интерфейс IDataAccessLayer имеет метод IEnumerable GetAllCars (), который возвращает список объектов DataAccessLayer.Car. Теперь мне нужно создать коллекцию MVCProject.Car, перебрать IEnumerable, возвращаемый GetAllCars (), на каждой итерации мне нужно создать новый объект MVCProject.Car, заполнить свойства Engine и Wheel и, наконец, добавить этот объект вКоллекция.

Итак: каждый раз мне приходится создавать почти одинаковые структуры и как-то управлять ими в разных местах.

Вот в чем проблема, понимаете?Или это не так?Я чувствую, что это превратится в большой беспорядок, если я не изменю это.Не повторяйте принципиальное нарушение как оно есть.Подскажите пожалуйста как правильно сделать.Используя я не знаю прокси или прототипы или, может быть, какой-то другой шаблон дизайна, который я в любом случае сосу.Или какой-то инструмент, такой как Ninject (который я знаю только как использовать в качестве контейнера IOC) или Automapper или что-то еще, что я, вероятно, высосу даже больше, чем шаблоны проектирования.

Answer 1

Я также не вижу особой причины отделять DAL от слоя MVC. Если вам интересно, вот макет, который я использовал для нескольких проектов, и я считаю его очень удобным и гибким.

DataObjects Основные объекты с только свойствами. Также включает перечисления, которые используют объекты DataObject.

DataAccess Наследуйте от DataObjects и добавьте GetByPrimaryKey, GetByForeignKey, GetByUniqueIndex, GetAll и т. Д. И т. Д. И т. Д. Также содержит слой Caching, где вы найдете StateCache, CountryCache и т. Д. Для быстрого доступа к часто используемым вещам. Методы «GetBy» будут использовать слой кэширования всякий раз, когда это возможно.

Logic Статические классы, по одному для каждого типа DataObject \ Access. Включает в себя логическую работу, отличную от простых выборок, как описано в слое DataAccess.

Web \ Интерфейсный Пользовательский интерфейс работает со слоями DataAccess и Logic для получения и обновления объектов, а также для вызова других определенных логических API.

Я использую свой собственный генератор кода для создания 98% этого кода (кроме уровня пользовательского интерфейса).

Answer 2

Похоже, ваша библиотека MVC должна знать о вашей библиотеке доступа к данным, не так ли?

Или, если вы действительно хотите разделить библиотеки MVC и DAL,Вы всегда можете добавить третью библиотеку со ссылками на MVC и DAL.Тогда он мог бы обрабатывать извлечение автомобилей из одной библиотеки и преобразовывать их в другую.

Но опять же, я не понимаю, почему ваши контроллеры (или ViewModel, из того, что вы описали) не должны иметьдоступ к DAL.ViewModel вашего автомобиля будет извлекать экземпляры автомобилей из DAL и отправляться оттуда.До тех пор, пока способ, которым он получает автомобили, закодирован через интерфейс, вы сможете отменить его позже для своих юнит-тестов.

EDIT

Похоже, вы думаете, что позже будете менять весь DAL, и вы хотите минимизировать сложность этого?Если это так, вы можете взглянуть на шаблон адаптера .Вы бы передавали все свои объекты DAL адаптерам, которые возвращали бы вам объекты на вашем бизнес-уровне.Затем, если ваш DAL изменяется, вы просто обновляете свои адаптеры.

Answer 3

Я нашел способ сделать его действительно уродливым:)

Цель: вызывающая сторона ничего не знает о сущностях модели в DataAccessLayer и получает все данные через интерфейс.Как получить данные без ручного сопоставления между Model и Viewmodel?Сквозь отражение.

 public IEnumerable<T> GetCars<T>()
    {
        var lst = new List<T>();

        _data.GetTable<Cars>().ToList().ForEach(x =>
        {
            var newCar = Activator.CreateInstance<T>();
            typeof(T).GetProperty("Engine").SetValue(newCar, x.Engine, null);
            typeof(T).GetProperty("Wheel").SetValue(newCar, x.Wheel, null);
            lst.Add(newCar);
        });

        return lst;
    }

Это работает.Но самый большой вопрос здесь - это справедливое и значительное архитектурное решение?Как повлияет производительность на приложение в реальной жизни?