Каков наилучший способ создания модели просмотра?

Question

Я использую asp.net mvc с инфраструктурой сущности и начинаю изучать DDD. Я работаю над проектом, который содержит обзоры. Вот моя модель предметной области:

public class Survey 
{ 
    public int? SurveyID { get; set; } 
    public string Name { get; set; } 
    public decimal MinAcceptanceScore { get; set; } 
    public int UserFailsCount { get; set; } 

    public IEnumerable<SurveyQuestion> Questions { get; set; } 
    public IEnumerable<Prize> Prizes { get; set; } 
    public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
} 

мне нужны разные части изысканий для различных взглядов, так что я создал различные ViewModels:

public class ShortSurveyViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public int UserFailsCount { get; set; } 
     public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
    } 

    public class ShortSurveyWithPrizesViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public int UserFailsCount { get; set; } 
     public IEnumerable<SurveyAttempt> UserAttempts { get; set; } 
     public IEnumerable<Prize> Prizes { get; set; } 
    } 

    public class SurveyEditViewModel 
    { 
     public int? SurveyID { get; set; } 
     public string Name { get; set; } 
     public decimal MinAcceptanceScore { get; set; } 
     public int UserFailsCount { get; set; } 

     public IEnumerable<SurveyQuestion> Questions { get; set; } 
     public IEnumerable<Prize> Prizes { get; set; } 
    } 

Что бы лучший способ построить свою архитектуру, если я хочу, чтобы мои репозиторий для получения информации, необходимой для модели одобрения?

Различные solusions, что я вижу:

1. Repository может вернуться IQueryable в SurveyService и сервис может вернуть модель представления appropriete, но я стеснялся, что делает это правильно, потому что я думаю, что вид модели должны быть созданы в пользовательском интерфейсе , а не Сервисный уровень.

2. Создайте три подходящих класса в моем доменном слое. Но теперь домен будет зависеть от представления и при каждом новом представлении должен быть создан новый класс домена.

3. Получить полный объект домена и отобразить только объекты, необходимые для конкретного вида. Это не хорошо, потому что в моем примере вопросы нужны только в одном представлении, и это может быть тяжелая коллекция.

Answer 1

домена Driven Design:

• Вы должны иметь хранилище возвращающегося совокупный корень - в вашем случае Survey и все отношения, которые не могут существовать без родительского Survey
• Это хранилище будет загружаться всегда весь Survey класс и в зависимости от ваши требования только некоторые отношения (действительно догматический DDD всегда будет загружать весь агрегат, но это не очень хороший подход для веб-сайта без учета состояния).
• Ваш прикладной уровень (контроллер) запросит репозиторий для Survey и выберет отношения и отобразит модели.

Луковый архитектура:

• Вы создадите некоторое хранилище разоблачением IQueryable<Survey> - еще хуже, вы будете использовать общий репозиторий с интерфейсом CRUD
• Вы будете создавать некоторые службы призывающую хранилищу и строительство Linq-на-субъектов проекция в ваши DTO и возврат их на прикладной уровень (контроллер)
• Теперь что? Вы можете использовать эти DTOs непосредственно или использовать другой набор предметов, используемых в качестве вашей модели зрения с некоторыми атрибутами, связанные с UI и т.д. Существует, очевидно, что-то не так ...

Простая архитектура:

• Вы будете использование впрыскивается IDbSet<Survey> непосредственно в контроллере как хранилище
• Вы сделать Linq-на-проекции образований непосредственно в контроллере, чтобы заполнить вид модели

Ther e не лучший способ. Это всегда о вашей цели и ваших ожиданиях. Для небольших приложений вы можете жить с простой архитектурой без каких-либо проблем.

Домен управляемый дизайн более сложный. Основной концепцией DDD являются объекты домена, объекты ценности и их состав. Объект домена инкапсулирует данные и логику, выполненные по этим данным. DDD не работает с частичными данными или DTO - когда ваши объекты домена не имеют никакой логики, вы делаете это неправильно (это называется анемической моделью). Служба в DDD не является посредником между уровнем приложения и репозиторием. Он используется для обработки бизнес-логики, которая не связана с единственным доменным объектом (поэтому не может быть инкапсулирована в сущности домена). Репозиторий - это код инфраструктуры, необходимый для материализации ваших агрегатов из хранилища и сохранения их в хранилище. Логика приложения (контроллер) может взаимодействовать с объектами домена, службами и кодом инфраструктуры.

Мне не нравится луковая архитектура.

Answer 2

Учитывая тот факт, что ваша главная задача является объем данных извлекается из модели данных в сопоставлении с количеством данных, необходимых в виде модели, я бы сказал, что правильный подход для вас будет строить просмотров в базы данных и их соответствующих моделей данных.

Это позволит вам обрезать объем данных, извлекаемых из базы данных, в любой поездке.

Хотя модели данных почти имитируют модели просмотра, это не проблема, они служат двум различным целям. Модель просмотра предназначена для представления для привязки - модель данных знает, как получить и сохранить данные. Построение этих представлений позволит вам получить данные оптимальным образом - и тем не менее выберете пользовательскую логику сохранения в тех же моделях, чтобы сделать их доступными для записи, если это необходимо, поэтому возникает необходимость в том, чтобы модель данных прошла перемещение данных с одного уровня на другой.