Во всех решениях, которые я реализовал такого рода, здравый смысл обычно требует, чтобы вы просто сообщали об ошибке из DAL.
Транзакционно выполняя любые изменения в БД, вы гарантируете откат и завершениесобственное исключение, в котором говорится, что произошло внутреннее исключение, и в результате не было внесено никаких изменений.
В BLL исключение затем перехватывается, а затем генерируется как пользовательское «BusinessProcessException» для вызывающего приложения.При желании BLL, потому что он находится в собственном «ящике», так сказать, иногда имеет свой собственный механизм ведения журнала для регистрации исключений, связанных с бизнес-процессами.
Прогнозировать, зарегистрирован он или нет на уровне BLL, вам все равно нужно сообщить об этомУровень пользовательского интерфейса (клиентское приложение), в котором возникла исключительная ситуация и был зарегистрирован, передавая полное дерево исключений.
Код клиентского приложения на уровне пользовательского интерфейса может иметь собственный журнал, но он не будет журналом, используемым BLL.
Цикл событий выглядит примерно так ...
Приложение вызывает метод bll, метод bll вызывает метод dal, метод dal вызывает хранимую процедуру на базе данных, хранящейся при обработке ошибок в базе данных (например)новое исключение dal с sqlexception в качестве внутреннего bll обрабатывает исключение dal и регистрирует ошибку dal, если в вызываемом методе bll есть какой-то транзакционный элемент, bll откатывает другие вызовы.bll выбрасывает новую исключительную ситуацию фреймворка bll. Внутреннее исключение dal Приложение обрабатывает исключение bll и решает, что делать с пользовательским интерфейсом из полного дерева исключений.
Это почти то же, что и все .net.
Вещи, на которые следует обратить внимание:
Если у меня есть бизнес-объект, который не проходит вызов обновления, этот бизнес-объект может иметь несколько дочерних объектов, которые обновляются как часть этого вызова.Эти дочерние объекты могут быть собраны из нескольких конечных точек dal на разных серверах, и каждой конечной точке dal может потребоваться обновить несколько записей в потенциально нескольких дБ
Таким образом, у вас есть транзакция для логики bll, и 1 для каждого dal вызывает внутренние операции, а затем потенциально 1 в каждом сохраненном вызове proc.
То, что .net делает в фоновом режиме, это стек их таким образом, что если транзакция на уровне bll завершается неудачно и вызывается откат, она должна откатить все дочерние элементытранзакции, однако в реальном мире, где транзакции охватывают системы и часто сети, это может быть невозможно.
Поэтому вы должны исходить из того, что предпринимаемые вами действия могут быть неудачными и могут быть отменены, если какая-либо часть иерархии завершится неудачно, и за это отвечает код, выполняющий вызов.
в конечном итоге это означает, чтовам нужен полный контрольный журнал того, что произошло.как bll dev, я записываю все, что делает мой фреймворк, в sql также есть журналы транзакций, поэтому многие реализации dal упрощены в этом отношении.
Приложения имеют (для asp.net) журналы сервера или только пользовательские параметры.
Единственное, что я бы порекомендовал, - это чтобы каждый слой регистрировал свою собственную активность и журналы были разделены (например, ошибка, связанная с пользовательским интерфейсом, на самом деле не относится к журналу bll)