Как проверить в доменном слое

Question

Я часто вижу людей, проверяющих объекты домена, создавая объекты правил, которые принимают делегата для выполнения проверки.Например, в этом примере ": http://www.codeproject.com/KB/cs/DelegateBusinessObjects.aspx

Чего я не понимаю, так как это выгодно сказать, просто делая метод?

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

Но разве это не то же самое, что просто иметь что-то вроде:

Bool validate()
{
    Result = string.IsNullOrEmpty(name);
}

Зачем пытаться создать объект для храненияПравило и определение правила в делегате, когда эти правила чувствительны к контексту и, вероятно, не будут использоваться совместно. То же самое может быть достигнуто с помощью методов.

Answer 1

Очевидным примером здесь является веб-приложение: вы заполняете форму и нажимаете «отправить». Некоторые из ваших данных неверны. Что происходит?

• Что-то выдает исключение. Что-то (возможно, выше) перехватывает исключение и печатает его (возможно, вы перехватываете только UserInputInvalidExceptions, при условии, что другие исключения должны быть просто зарегистрированы). Вы видите первое, что было не так.
• Вы пишете функцию validate (). Это говорит "нет". Что вы показываете пользователю?
• Вы пишете функцию validate (), которая возвращает (или выдает исключение, или добавляет) список сообщений. Вы отображаете сообщения ... но не было бы неплохо группировать по полю? Или отобразить его рядом с полем, которое было неправильным? Используете ли вы список кортежа или кортежа списков? Сколько строк вы хотите, чтобы правило занимало?

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

Answer 2

Есть несколько причин:

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

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

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

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