Должны ли бизнес-объекты или сущности самообслуживаться?

Question

Валидация бизнес-объектов - распространенная проблема, но есть некоторые решения для решения этой проблемы.

Одним из таких решений является использование автономной инфраструктуры NHibernate.Validator, которая является основанной на атрибутах структурой.

Но я столкнулся с концептуальной проблемой. Валидаторы атрибутов, такие как NH.Validator, отличные, но проверка выполняется только при сохранении-обновлении-удалении в сеансе.

Итак, интересно ли, чтобы бизнес-объекты не были самооценены, чтобы сохранить свою целостность и целостность?

Answer 1

ИМХО - есть 2 шага валидаций, необходимые для бизнес-объекта (BO)/Entity быть действительным:

Шаг1: BO/Entity самопроверки - В этом, мы проверяем только если сущность действительна в терминах ее состояния F.Ex .: Если установлен почтовый код, то имеет ли он действительные символы & имеет допустимую длину и т. д. формирует проверки уровня BO/Entity. Но помимо этого уровня проверки мы не сможем сказать, что BO/Entity действителен в вашем бизнес-домене и/или репозитории. Как правило, BO/Entity сможет обеспечить такой уровень проверки.

Шаг2: Контекст проверки - В этом, мы должны проверить, если BO/Entity действует в контексте Repository, где в настоящее время сохранялось. F.Ex .: Является ли почтовый индекс действительным для страны, в которой размещается/отправляется заказ и т. Д. Для этой проверки могут потребоваться некоторые или все объекты в текущем контексте, чтобы убедиться, что BO/Entity действует.

Таким образом, чтобы сохранить сущности чистыми, вам необходимо разделить валидацию на эти 2 шага - одну, выполненную самим объектом &, вторым хранилищем, которое сохраняется/работает с сущностью.

HTH.

Answer 2

Это не всегда возможно для их самооценки. Что делать, если вы вводите «недопустимый» почтовый индекс? Вы можете подтвердить, что почтовый индекс должен быть в определенном формате, но что, если вы хотите, чтобы они были «действительными», то есть «существующими и соответствующими городу»? Или что, если вы принимаете только номера телефонов из определенных кодов областей, а список действительных кодов находится в базе данных, поддерживаемой юридическим отделом?

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

Answer 3

Я не знаю, говорим ли мы об одной и той же идее, но если да, мне нравится то, что вы объясняете. Очень быстро, я объясню, что я делаю, чтобы решить эту проблему. В моем случае все объекты бизнес-класса в моем доменном слое должны переопределить два метода:

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

List<ValidationRule> notPassedValidationRules = new List<ValidationRule>(); 

//... 

public override void ValidateErrorsWhenSaving(Validator validator) 
{ 
    //... 
} 

public override void ValidateErrorsWhenDelete(Validator validator) 
{ 
    //... 
}   

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