Проверка в 3-уровневой архитектуре

Question

Предположим, что существует класс Employee, одним из бизнес-требований является то, что EmployeeName становится уникальным. Теперь, используя 3 уровневую архитектуру,

Этап 1: Презентация
Tier 2: Классы Модели предметной области + Service Data (Business Logic Layer)
Tier 3: Классы доступа к данным + хранимые процедуры доступа (уровень данных)

Поскольку требование выше - деловое требование, где, по вашему мнению, лучшее место для размещения этого правила?

Вариант 1: Уникальный ключ ограничение в базе данных

Вариант 2: используется Проверка состояния в классе обслуживания данных в бизнес-уровне для того, чтобы сохранить бизнес-логику, инкапсулированную в этом слое, независимо от уровня данных?

Answer 1

Во всех трех слоях. Однако важным является тот факт, что требования валидации (= фактические ограничения данных) отличаются от уровня к слою. Это из-за различного контекста и разработанных границ системы.

В вашем примере, проверка может быть следующим:

• Этап 1: Презентация слой - проверить, что имя было введено, то есть текстовое поле в интерфейсе пользователя не является пустым, и имеет не более 100 символов.
• Уровень 2: уровень бизнес-логики - подтвердите, как указано выше, плюс он состоит из по меньшей мере двух токенов, разделенных пробелом, а также имена первых и последних имен - это настоящие имена и фамилии (chek против некоторой базы данных имен).
• Уровень 3: Уровень данных - ограничение целостности базы данных, что соответствующее поле не пусто и имеет максимальную длину 100 символов.

Результатом является то, что с точки зрения базы данных вы проверяете разумное количество ограничений, чтобы поддерживать целостность системы, но не предполагайте, что является вопросом логики более высокого порядка. Фактически, вы не ограничиваете будущие изменения без необходимости. С точки зрения бизнес-логики существует полный набор ограничений. И, наконец, с точки зрения логики представления, вы не делаете overvalidate: выполняются только простые проверки для уменьшения ненужного трафика в бизнес-логику, что предотвращает исключения из уровня бизнес-логики, а не дублирует что-либо более сложное.

Как правило, это всегда Лучшая практика для предоставления подробных валидаций на фасаде уровня бизнес-логики. Это место, где подключаются (потенциально ненадежный) уровень представления и/или сторонняя (которые могут быть только другой корпоративной системой) потребители API.

Кроме того, некоторые конкретные замечания к опциям, изложенным в вашем вопросе:

Вариант 1: Уникальный ключ ограничение в базе данных

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

Вариант 2: Проверка условий в классе Data Service на бизнес-уровне, чтобы сохранить бизнес-логику, инкапсулированную в этот слой, независимо от используемого слоя данных.

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