Проверка на доменные объекты вместе с MVP

Question

Как применить проверку в среде MVP / домена?

Позвольте мне уточнить на примере:

Сущность домена:

class Customer
{
  string Name;
  etc.
}

MVP-модель

class CustomerModel
{
   string Name;
   etc.
}

Я хочу применить проверку к моим доменным объектам, но модель MVP имеет свою собственную модель / класс отдельно от доменного объекта, означает ли это, что я должен скопировать код проверки, чтобы также работать с MVP-модель?

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

Третья вещь с этим подходом - это если пользователь редактирует некоторые данные, а затем отменяетредактировать, как мне вернуться к старым значениям?(Сущность может не приходить из БД, поэтому перезагрузка сущности возможна не во всех случаях).

Другое решение состоит в том, чтобы сделать своего рода копию / клон рассматриваемой сущности и использовать копию в качестве MVP.-моделировать, но тогда может возникнуть проблема, если у сущности есть большой граф объектов.

У кого-нибудь есть несколько советов по этим проблемам?

Answer 1

Ограничение чего-то вроде имени человека, вероятно, не по праву принадлежит модели домена, если только в компании клиента не существует правила, согласно которому они не ведут дела с клиентами, чьи имена превышают 96 символов.

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

С одной стороны,Вы хотите быть уверены, что ваша модель человека является полной и точной, но подумайте о человеке «реального мира», которого вы моделируете.Нет никаких правил о длине и нет логического следствия для «ой, была проблема, пытаясь дать этому человеку имя».У человека просто есть имя, поэтому я бы поспорил с тем, что докладчик должен проверить, что пользователь вводит, прежде чем заполнять модель предметной области, потому что формат данных является задачей приложения.больше, чем домен.

Кроме того, как объясняет Уди Дахан в своей статье Использование шаблона модели домена , мы используем шаблон модели домена для инкапсуляции правил, которые могут быть изменены.То, что у человека не должно быть нулевого имени, не является требованием, которое, вероятно, когда-либо изменится.

Я мог бы рассмотреть возможность использования Debug.Assert() в объекте домена только для дополнительного уровня защиты посредством интеграции и / илиручное тестирование, если я действительно обеспокоен тем, что в него проскальзывает нулевое имя, но что-то вроде длины, опять же, здесь не принадлежит.

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

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

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