BL против DAL, когда проверка требует DB

Question

Я планирую поставить логику проверки в бизнес-логике, которая может включать в себя такие вещи, как:

[Required], [Length > 0] и т.д. Использование аннотаций данных. Тем не менее, мне также нужно правило проверки, которое проверяет, что объект не является дубликатом, перед тем как вставить DAL в базу данных, например. [IsDuplicate]. Итак, вопрос в том, где ввести правило проверки [IsDuplicate]? Если я поместил его в свой BL, то это нарушит мою текущую трехуровневую настройку, где BL не знает DAL. Я думаю, что вопрос действительно становится, проверяет ли дубликаты правильное правило валидации или что-то еще?

Answer 1

Ваш вопрос неоднозначен. Это зависит от того, какую запись и какую операцию вы ссылаетесь.

Если вы обратитесь к один ко многим записи, как:

header --> many details 

BL

Затем проверка дублирования делается в BL. То есть, например, подтвердите, если деталь заголовка не должна содержать два или более одинаковых кода элемента и т. Д. И если процесс принимает массив заголовков, дублируемая проверка заголовка также выполняется в BL.

Другие правила валидации, такие как минимальная длина, формат строки, нулевые значения и т. Д., Также выполняются в BL. Он может быть автоматически повторно проверен в DB, хотя, если вы используете некоторые ограничения и тип данных/isnull.

DAL

Однако, если вы хотите проверить, если идентификатор заголовка уже существует в DB, сделайте это в DAL. Это потому, что BL не знают, что это такое в репозитории. Это DAL.

Есть некоторые случаи, когда вам не нужно сначала выполнять проверку, например, если таблица заголовков уже имеет уникальный индекс, она будет генерировать исключение, и вам просто нужно ее поймать.Однако для конкретных DB проверка проверки вроде: item не существует, количество предметов недостаточно, определенного пользователя не существует, вы должны сделать это в DAL или использовать хранимую процедуру для него.

Но любая проверка в DAL, должен быть вызван из BL и избежать прямого вызова из UI.

Answer 2

Вы должны проверить его дважды.

Однажды в BL, чтобы показать пользователю нормальное сообщение, он ввел уже существующее значение.

Во второй раз вы должны проверить свой DAL, что вы не пытаетесь вставить уникальное значение (как это делает UNIQUE CONSTRAINT в базе данных), потому что вы не знаете, кто его будет использовать, в таких case выдает пользовательское исключение, которое может быть понято кем-то новым, использующим ваш слой DAL.

Answer 3

Я придерживаюсь мнения, что игра в ультрабезопасность душна. Проверяйте обход только в BL и приносите весь список объектов через dal-вызов. Однако, если список объектов слишком велик, вам, возможно, придется переупаковать в хранимой процедуре/слоте DAL