ЛУЧШИЙ подход к обмену сообщениями между уровнем данных и уровнем приложения

Question

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

Я обычно использую две переменные в каждой процедуре хранения:

@code INT,
@message VARCHAR(1024)

Я помещаю операторы DML внутриTRY CATCH блок и в конце блока try установите обе переменные в определенное состояние, означающее, что все прошло нормально, так как вы можете подумать, что я делаю противоположное в блоке catch, установите обе переменные в некоторый код ошибки, если необходимо, выполните некоторую ошибкуобработка.

После блока TRY CATCH я возвращаю результат, используя запись:

SELECT @code AS code, @message AS message

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

Возможно, я скучаю по имПортантные функции, такие как RAISERROR или не подходящие лучше и более оптимальные и безопасные подходы.

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

Спасибо

Answer 1

Общепринятый подход для решения этой проблемы состоит в том, чтобы ваш sproc устанавливал возвращаемые значения и используйте ошибку повышения, как было предложено ранее.

Я подозреваю, что вам не хватает ключевой вещи - как вернуть эти данные на стороне клиента.

Если вы находитесь в среде .net, вы можете проверить возвращаемое значение как часть кода ado.net. Сообщения об ошибках повышения могут быть получены путем перехвата объекта SqlException и повторения сбора ошибок.

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

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

Answer 2

Мой опыт заключается в том, чтобы полагаться на внутреннюю работу механизмов процедуры. Под этим я подразумеваю, что если процедура должна завершиться с ошибкой, либо неявная ошибка (если не используется try / catch ... просто CRUD) или явный RAISERROR. Это означает, что если код попадает в блок catch, и я хочу уведомить приложение об ошибке, я бы повторно поднял ошибку с помощью RAISERROR. В прошлом я создавал пользовательскую процедуру повторного выброса, чтобы я мог перехватывать и регистрировать информацию об ошибках. Можно использовать rethrow как возможность выбросить пользовательское сообщение / код, который можно использовать для направления приложения по другому пути принятия решения. Если вызывающее приложение не получает ошибку при выполнении, можно с уверенностью предположить, что оно выполнено успешно, поэтому может начаться явное принятие транзакции.

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

Надеюсь, я не неправильно понял, что вы делаете, и при этом я не хочу показаться критичным; Однако я уверен, что у вас есть этот механизм обратной связи со стандартным API, и, вероятно, вы делаете это слишком сложным. Я бы порекомендовал прочитать по RAISERROR и посмотреть, будет ли он соответствовать вашим потребностям (см. Также ссылку Использование RAISERROR в нижней части страницы).