Бизнес-объекты или Объекты должны быть Самопроверены?
Проверка Бизнес-объектов является распространенной проблемой, но существуют некоторые решения решить это.
Одно из этих решений состоит в том, чтобы использовать автономный NHibernate. Платформа блока проверки допустимости, которая является основанной на атрибуте платформой проверки.
Но я сталкиваюсь в концептуальное беспокойство. Блоки проверки допустимости атрибута как NH.Validator являются большими, но проверка только выполняется когда save-update-delete в рамках Сессии.
Так интересно, не должны ли бизнес-объекты быть самопроверены для поддержания их собственной целостности и последовательности?
3 ответа
ИМХО - есть 2 этапа проверки, необходимые для того, чтобы бизнес-объект (BO)/сущность были валидными:
Шаг1: самопроверка BO/Entity - В этом случае мы проверяем только, является ли объект действительным с точки зрения его состояния Например: если задан почтовый индекс, то имеет ли он допустимые символы, допустимую длину и т.д. - это проверка на уровне объекта BO/Entity. Но за пределами этого уровня проверки мы не сможем сказать, что BO/Entity действителен в вашем бизнес-домене и/или хранилище. Как правило, BO/Entity может обеспечить этот уровень валидации.
Шаг 2: Проверка контекста - Здесь нам нужно проверить, является ли BO/сущность действительной в контексте хранилища, в котором она сохраняется. Например: действителен ли почтовый индекс для страны, в которой размещается/отправляется заказ и т.д. Для такой проверки может потребоваться участие некоторых или всех сущностей в текущем контексте, чтобы убедиться, что BO/Entity действителен.
Таким образом, чтобы сохранить чистоту сущностей, вам нужно разделить проверку на эти 2 этапа - один выполняется самой сущностью, а второй - хранилищем, которое перситирует/работает с сущностью.
HTH.
Однако они не всегда могут пройти самопроверку. Что, если вы введете «недействительный» почтовый индекс? Вы можете подтвердить, что почтовый индекс должен быть в определенном формате, но что, если вы хотите, чтобы они были «действительными», то есть «существующими и соответствующими городу»? Или что, если вы принимаете телефонные номера только из определенных кодов регионов, а список допустимых кодов находится в базе данных, поддерживаемой юридическим отделом?
Если вы можете выполнить семантическую проверку, это здорово и может войти в бизнес-класс. Но часто вам может потребоваться дополнительная проверка, которую просто невозможно обработать самим бизнес-классом, но она должна выполняться классом, который общается с базой данных и другими внешними службами.
Не знаю, говорим ли мы об одной и той же идее, но если да, то мне нравится то, что вы объясняете. Очень быстро я объясню, что я делаю, чтобы решить эту проблему. В моем случае все бизнес-объекты в моем доменном слое должны переопределять два метода:
Очевидно, что для поддержания этого у меня задействовано больше классов, но я не буду писать здесь все, потому что я только пытаюсь объяснить concept
List<ValidationRule> notPassedValidationRules = new List<ValidationRule>();
//...
public override void ValidateErrorsWhenSaving(Validator validator)
{
//...
}
public override void ValidateErrorsWhenDelete(Validator validator)
{
//...
}
В этих методах я проверяю некоторые логические условия, сохраняя набор непринятых правил. В моем случае эти методы вызываются до того, как мой Unit Of Work фиксирует изменения (вставка новых сущностей, обновление, удаление) и показывает пользователю возможные ошибки перед фиксацией.