Если я проверяю на ограничения DB в коде или если я ловлю исключения, выданные DB

Ответ: оба.

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

• Если у Вас будет ошибка в Вашем приложении, то нарушение ограничения отметит что-то, что не могло бы иначе быть замечено.

• Другие пользователи базы данных могут принять больше о поведении данных, поскольку DBMS осуществляет инварианты.

• База данных защищает себя от неправильных обновлений, которые нарушают ограничения. Если Вы находите, что у Вас есть некоторая другая система или интерфейс, заполняющий базу данных вниз дорожка, ограничения, осуществленные базой данных, означают, что что-либо пойманное ограничениями не будет (или по крайней мере менее вероятно), повреждают Вашу систему.

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

Я оставил бы ту работу полностью базе данных; Ваш код должен сфокусироваться на ловле и правильно обрабатывании исключения.

Причины:

1. Производительность - база данных будет высоко оптимизирована для осуществления ограничений быстрым и эффективным способом. У Вас не будет времени для оптимизации кода также.
2. Пригодность для обслуживания - Если ограничения изменяются в будущем, Вы не должны будете изменять свой код, или возможно необходимо будет просто добавить новую выгоду {}. Если ограничение отбрасывается, Вы не должны будете касаться своего кода вообще.

Если бы Ваш дизайн хорош (и база данных и BL), база данных не должна иметь никаких ограничений, с которыми не имели бы дело в BL - т.е. Вы не должны дарить базе данных непоследовательные данные. Но ничто не прекрасно.

Я нашел, что ограничение базы данных к ограничениям непротиворечивости данных позволяет мне обработать всю проверку BL в процессуальном кодексе, и единственные случаи, где я испытываю исключения базы данных, являются ошибками дизайна и кодирования, которые могут (и должен быть), зафиксированный.

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

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

В большинстве случаев я сказал бы, предоставляют DAL право ловить порожденные из DB исключения. Но в Вашем конкретном случае, я думаю, что мы говорим об основном контроле ввода. Я выбрал бы вызов проверки доступности имени к базе данных, прежде, чем отправить целую форму.

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

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

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

The inner exception of the GenericADOException will tell you why the database action failed. You can catch the OracleException / MSSQLException / [InsertCustomExceptionHere] and handle the error from that message. If you want to pass this back up to the front end (assuming the user is the one who entered duplicate data) you might want to wrap it in a custom exception first so you don't couple your front end to your database. You don't really want to be passing RDBMS specific exceptions around.

I disagree with checking the db for uniqueness before doing an insert, round tripping to the database twice isn't very efficient and certainly isn't scalable if you have a high volume of user traffic.

Лично я поймал бы исключение. Это намного более просто и требует намного меньшего количества кода.

Вопрос, который вам нужно ответить, это:

«Мне нужно представить пользователю приятными сообщениями». Пример: уже есть работа с именем TestJob1. Если ответ NO , просто поймите ошибку и представьте общее сообщение Если ответ Да , продолжайте чтение

, если вы Поймать ошибку после вставки Недостаточно информации, чтобы представить правильное сообщение (по крайней мере, в пути Agnostic DB )

С другой стороны, могут быть условия расы , и вы можете иметь одновременную транзакцию, пытаясь вставить те же данные, поэтому вам нужно ограничение DB

подход, который хорошо работает это:

• Проверьте, прежде чем представить хороший сообщение
• Поймай исключение и Представьте общее сообщение об ошибке (Предполагая, что это не произойдет очень Часто)