Преимущества не проходящих лиц для просмотра - PullRequest
Новая
       29

Преимущества не проходящих лиц для просмотра

2 голосов
/ 23 октября 2011

Я обычно вижу людей, которые говорят, что вы не должны передавать сущности в свой View. Они говорят, что вы должны использовать DTO / VO / ViewModel / AnyOtherThingYouWant вместо этого, так как использование объекта увеличит связь. Не обращая внимания на моменты, когда мне нужна дополнительная логика (или мне не нужны все свойства), я не вижу никаких преимуществ в этом. Например, рассмотрим следующий класс: 

public class Contact {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

Я вижу много кода, который создает другой класс, например: 

public class ContactDTO {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

используйте его в представлении, а затем сделайте следующее: 

someMapper.Map(contactDto).To<Contact>();

Я не могу понять, насколько это лучше, чем просто использовать класс Contact, так как ваш View будет связан с классом, который связан с классом сущности. Таким образом, каждое изменение в одном должно копироваться в другое. С моей точки зрения, «средний» объект - это просто добавление сложности, но не реальная ценность. Я знаю, что не существует решения «один размер подходит всем» (как иногда, использование среднего объекта имело бы смысл), но нужно ли нам добавлять такой код? Каковы реальные преимущества?

Ответы [ 2 ]

4 голосов
/ 24 октября 2011

Думайте об этом так: представление - это проекция вашего домена.Это конкретное представление вашей бизнес-модели.Поэтому вам нужно использовать модель представления, которая будет представлять эту проекцию.Это может быть подмножество модели предметной области, но это также может быть объединение нескольких моделей предметной области, если представление требует этого.Приведенный вами пример представляет собой лишь конкретный случай, когда между моделью домена и моделью представления существует соотношение 1: 1 из-за требований этого конкретного представления.Но это только одна конкретная точка зрения.Я полагаю, что ваше приложение имеет много представлений и разных представлений сущностей вашего домена.

Существует множество конкретных представлений, которые делают модели вашего домена неподходящими и, следовательно, нуждаются в моделях представлений.Например проверка.Заданное свойство модели домена может требоваться в одном представлении и не требоваться в другом представлении (представьте свойство Id в представлениях «Создание / обновление»).Если вы не используете модель представления, но ваше действие «Создать контроллер» напрямую использует модель домена, у вас возникнет проблема, если свойство идентификатора вашей модели домена будет иметь атрибут Required.

Есть много других примеров.Если бы у меня был один совет при разработке приложения ASP.NET MVC, это было бы так: всегда определяйте конкретные модели представлений для ваших представлений и никогда не передавайте / переносите доменные модели в / из представлений, и это верно даже в случаях, когдасоотношение 1: 1 между вашей моделью домена и моделью представления.

3 голосов
/ 24 октября 2011

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

Таким образом, вы должны принять во внимание то, что сказал Дарин Димитров, но имейте в виду, что DTO и подобные организации здесь, чтобы облегчить вашу работу.Я вспоминаю один проект, над которым я работал - более 90% DTO были одно-копийными объектами домена - это абсолютно бесполезно и только увеличивает стоимость обслуживания.

...