Является ли модель привязки доменов плохой идеей? - PullRequest
Новая
       12

Является ли модель привязки доменов плохой идеей?

1 голос
/ 24 февраля 2011

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

Если форма усложняется, я могу создать привязку к пользовательской модели.

Есть ли питфалы, использующие этот подход?

Я бы хотел избежать создания viewmodel, потому что я хочу, чтобы приложение было как можно более простым. Я бы хотел избежать дублирования кода и вида модели для привязки модели.

Ответы [ 3 ]

4 голосов
/ 24 февраля 2011

Не обязательно.Но вскоре вы найдете какое-то состояние, которое должно быть в модели, но зависит от пользовательского интерфейса, и вы все равно создадите ViewModel.

Также для некоторых свойств, таких как DateTime, это не будет хорошо работать в модели, если она определена как DateTime, поскольку существует проблема с ее необязательным назначением, поэтому вам нужно определить ее как string.И я не верю, что вы хотите поставить string для даты.

Кроме того, для предметов DropDown вам нужна коллекция для Модели для SelectListItem, которая не имеет смысла для Модели.

Вот что случилось со мной.

3 голосов
/ 24 февраля 2011

Я бы посоветовал почти всегда использовать модели представлений.

Если вы используете шаблоны объектов по умолчанию ... им действительно не нравятся неплоские модели, и хотя вы можете их переопределить,это не всегда хорошая идея.Доменные модели обычно не плоские.В любом случае, все, что основано на ModelMetaData, проще с ViewModel.

Проверка также проще с ViewModel, так как у вас есть более сфокусированная модель, и иногда есть проверка, которая имеет смысл только в некоторых представлениях.

Создание ViewModels намного лучше и безопаснее, чем отправка моделей с помощью JsonResult ... Что ж ... вам НИКОГДА не следует отправлять доменные модели вне системы, даже если вы не используете ViewModels.Но легче использовать JsonResult, когда у вас есть готовая ViewModel.Также легче делать ошибки и предоставлять конфиденциальную информацию, когда вы привыкли использовать свои доменные модели повсеместно.

Изменения иногда проще, потому что изменение свойства в доменной модели не означает, что вы должны изменить всеваши представления, просто измените создание ViewModel (если вы используете какой-то тип сопоставления, это всего лишь одно изменение в привязке), хотя это не очень сильный момент IMO.

Некоторые другие преимуществаотделяют уровень представления от бизнес-уровня, и если вы используете объекты EF или непоко, их будет сложнее использовать в представлениях.

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

Кстати, я не вижу, как создать связыватель пользовательской модели проще, чем использовать ViewModels.

1 голос
/ 24 февраля 2011

Я бы посоветовал вам всегда создавать ViewModel.В своей простейшей форме он может просто содержать свойство с объектом домена (и вспомогательными данными).Что-то вроде: 

public class DomainModelClass
{
    int Property1 { get; set; }
    int Property2 { get; set; }
}

public class ViewModelClass
{
    DomainModelClass DomainModel { get; set;}

    SelecList List1 { get; set; }
}

В любом случае, это предложение просто для простоты, потому что я бы посоветовал вам создать «настоящую» модель представления и использовать что-то вроде AutoMapper для отображения ViewModel <-> DomainModelдаже в простом сценарии.

...