Где вы помещаете валидацию в проекты с Domain Driven Design?

Question

Где я должен разместить логику проверки объектов Домена в моем решении?Должен ли я поместить их в классы доменов, бизнес-уровень или еще что-нибудь?

Я также хотел бы использовать для этого блоки приложений валидации и блока инъекций политики из библиотеки Microsoft Enterprise.

ЧтоСтратегию валидации, которую я должен использовать, чтобы все это хорошо сочеталось?

Спасибо всем заранее!

Answer 1

Это зависит.Первое - Вам необходимо понять, что Вы проверяете.

Вы можете проверить:

1. это значение, полученное из сообщения Http, может быть проанализировано как время даты,
2. , что Customer.Name не превышает 100 символов,
3. что у Клиента достаточно денег для покупки вещей.

Как видите, эти проверки различны по своей природе, поэтому их следует разделить .Их значение также различается (см. Параграф «Все правила не равны»).

---

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

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

Кроме того, вам следует рассмотреть возможность избежатьиспользование инструментов в модели вашего домена, поскольку она должна быть максимально свободной от инфраструктуры.

Другое дело - охватить использование объектов-ценностей.Они отлично подходят для проверки достоверности.

Answer 2

Вы можете сделать любой из них, в зависимости от ваших потребностей.

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

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

Хотя вы не можете комментировать блок приложения проверки. Как всегда вынадо взвесить все за и против, никогда не будет одного правильного решения.

Answer 3

Во-первых, я согласен с @ i8abug.

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

На каждом этапе вы должны спросить себя, каковы преимущества и недостатки данного вопроса в отношении вашего заявления.

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

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

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

Откровенно говоря, если вы пойдете по этому пути, то можете также определить все как структуру и позволить всем этим «вспомогательным» классам подкрасться назад, чтобы позаботиться о проверке, сохранении, настройке свойств и т. Д. класс почти ничего не покупает.

Все это говорит о том, что я склонен к самостоятельным занятиям. Другими словами, они знают, как их свойства связаны друг с другом, и знают, каковы допустимые значения. Они также могут выполнять операции над собой и своими детьми. Другими словами, они знают, что они есть. Это приводит к упрощенному кодированию и реализации. Это также приводит к точному знанию того, куда идти для модификации или изменения. Единственное разделение, которое я на самом деле делаю здесь, - это внедрение Inversion of Control для постоянства; что позволяет мне менять поставщиков данных во время выполнения; что было требованием для нескольких приложений, которые я сделал.

Дело в том, подумайте над тем, что вы делаете, и решите, действительно ли это лучший путь в вашей конкретной ситуации. Все эти «правила» программирования - всего лишь предложения.

Answer 4

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

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

Старый способ, которым яЯ сделал проверку, у меня был интерфейс IValidator, как показано ниже, который реализовал каждая сущность.

public interface IValidator
{
   IList<RuleViolation> GetViolations();
}

Теперь я делаю это с помощью NHibernate Validation (не нужно использовать nhibernate ORM, чтобы воспользоваться библиотекой проверки.сделано просто с помощью атрибутов.

//I can't remember the exact syntax but it is very similar to this
public class MyEntity
{

[NHibernateValidation(Length(min=1, max=10)]
public String Name {get;set;}

}

//... and then later ...
NHibernateValidator.Validate(myEntity);

Редактировать: я удалил свой комментарий о том, что в прошлом я не был большим поклонником корпоративной библиотеки в целом, так как Крис сообщил мне, что теперь она очень похожа на NHibernate Validation