Модели, ViewModels, DTO в приложении MVC 3

Ответ 1

ввести ViewModels, которые живут в Проект WebUI и выставить IQueryables и контекст данных EF из сервис для проекта WebUI. Затем я может напрямую проектировать в те ViewModels.

Проблема с этим заключается в том, что вы вскоре сталкиваетесь с проблемами, использующими EF, пытающиеся "сгладить" модели. Я столкнулся с чем-то подобным, когда у меня был класс CommentViewModel, который выглядел следующим образом:

public class CommentViewModel
{
    public string Content { get; set; }
    public string DateCreated { get; set; }
}

Следующая проекция запроса EF4 на CommentViewModel не будет работать, поскольку не может перевести метод ToString() в SQL:

var comments = from c in DbSet where c.PostId == postId 
               select new CommentViewModel() 
               { 
                   Content = c.Content,
                   DateCreated = c.DateCreated.ToShortTimeString() 
               };

Использование чего-то вроде Automapper - хороший выбор, особенно если у вас много конверсий. Тем не менее, вы также можете создавать свои собственные конвертеры, которые в основном конвертируют вашу модель домена в вашу модель просмотра. В моем случае я создал свои собственные методы расширения для преобразования моей модели домена Comment в my CommentViewModel следующим образом:

public static class ViewModelConverters
{
    public static CommentViewModel ToCommentViewModel(this Comment comment)
    {
        return new CommentViewModel() 
        { 
            Content = comment.Content,
            DateCreated = comment.DateCreated.ToShortDateString() 
        };
    }

    public static IEnumerable<CommentViewModel> ToCommentViewModelList(this IEnumerable<Comment> comments)
    {
        List<CommentViewModel> commentModels = new List<CommentViewModel>(comments.Count());

        foreach (var c in comments)
        {
            commentModels.Add(c.ToCommentViewModel());
        }

        return commentModels;
    }
}

В основном, я выполняю стандартный запрос EF, чтобы вернуть модель домена, а затем использовать методы расширения для преобразования результатов в модель представления. Например, следующие методы иллюстрируют использование:

public Comment GetComment(int commentId)
{
    return CommentRepository.GetById(commentId);
}

public CommentViewModel GetCommentViewModel(int commentId)
{
    return CommentRepository.GetById(commentId).ToCommentViewModel();
}

public IEnumerable<Comment> GetCommentsForPost(int postId)
{
    return CommentRepository.GetCommentsForPost(postId);
}

public IEnumerable<CommentViewModel> GetCommentViewModelsForPost(int postId)
{
    return CommentRepository.GetCommentsForPost(postId).ToCommentViewModelList();
}

Ответ 2

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

Таким образом, вы можете иметь свои сущности в Domain, а несколько классов модели представлений в вашем WebUI и где-нибудь (желательно в WebUI или подпространстве имен того же самого) определяют карты между ними. Ваши модели просмотра фактически будут DTO, но вам не придется беспокоиться о процессе преобразования между доменом и вашими классами DTO.

Примечание. Я бы настоятельно рекомендовал против предоставить сущности домена прямо в представлениях вашего веб-интерфейса MVC. Вы не хотите, чтобы EF "придерживался" до самого уровня интерфейса, если вы позже захотите использовать что-то другое, кроме EF.

Ответ 3

Говоря о моделях, ViewModels и DTO сбивает с толку, лично я не люблю использовать эти термины. Я предпочитаю говорить о Сущности домена, Доменные службы, Операция ввода/результат (также известный как DTO). Все эти типы находятся в доменном слое. Операции - это поведение объектов и служб. Если вы не создаете чисто CRUD-приложение, уровень представления относится только к типам ввода/результата, а не к объектам. Вам не нужны дополнительные типы ViewModel, это ViewModels (другими словами, модель представления). В представлении отображается перевод результатов операции в HTML, но тот же результат может быть сериализован как XML или JSON. То, что вы используете как ViewModel, является частью домена, а не уровня представления.