database - это - собственные исключения java

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

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

Нет чистого способа унифицировать эти три разных типа проверки в рамках одного компонента.

Предпринимаются некоторые попытки унифицировать межсекторальные обязанности, такие как проверка внутри инспекторов политики, таких как блок приложений внедрения политики P & P в сочетании с их блоком Application Validation , но они все еще основаны на коде. Если у вас есть проверка, которая не в коде, вам все равно придется поддерживать параллельную логику отдельно ...

В общем, я пытаюсь проверить данные как можно скорее после их ввода. Это так, что я могу дать полезные сообщения пользователю раньше, чем после того, как они нажали «отправить» или эквивалент.
К тому времени, когда речь заходит о создании вызова db, я надеюсь, что данные, которые я передаю, должны быть довольно хорошими.
Я пытаюсь сохранить вызовы db в одном файле (или группе файлов), которые используют вспомогательные методы, как можно проще для программиста (я или кто бы то ни было добавляет вызовы), чтобы записывать данные журнала об исключении и какие параметры были переданы и т. д.

Вы хотите уменьшить ненужные поездки в БД, поэтому выполнение проверки в приложении является хорошей практикой. Кроме того, он позволяет обрабатывать ошибки данных, с которыми он наиболее легко восстанавливается: рядом с пользовательским интерфейсом (будь то в контроллере или на уровне пользовательского интерфейса для более простых приложений), где вводятся данные.

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

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

Например, если у вас есть веб-приложение ASP.NET MVC, у вас есть три уровня (снизу вверх): база данных, контроллер и пользовательский интерфейс (модель, контроллер и представление). Любые ошибки, сброшенные вашим уровнем данных, должны быть разрешены для ввода пузырьков в ваш контроллер. На этом уровне ваше приложение «знает», что пытается сделать пользователь, и может правильно информировать пользователя об ошибке, предлагая различные способы его обработки. Попытка восстановить эти ошибки в слое данных затрудняет понимание того, что происходит внутри контроллера. И, конечно, размещение бизнес-логики в пользовательском интерфейсе не считается лучшей практикой.

TL; DR: проверять всюду, обрабатывать ошибки проверки в последний ответственный момент.

Инструмент объектно-реляционного сопоставления (ORM), такой как NHibernate (или, еще лучше, ActiveRecord ), может помочь вам избежать большого количества валидации, позволяя создать модель данных прямо в вашем коде как подходящий класс C #. Вы также можете избежать поездок в базу данных, благодаря отличным моделям кэширования и валидации, встроенным в инфраструктуру.

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

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