Должен ли я дублировать валидацию на моем уровне MVC и уровне сервиса? - PullRequest
7 голосов
/ 29 июня 2010

Я чувствую себя немного противоречивым в данный момент.У меня есть веб-приложение, использующее Stripes для инфраструктуры MVC и Spring / Hibernate для серверной части.У меня есть метод регистрации учетной записи в моем слое MVC, который требует следующей проверки:

  • Имя пользователя еще не занято
  • Указанный адрес электронной почты еще не связан с другой учетной записью

У меня есть метод проверки в Stripes (уровень MVC), который проверяет эти два случая, но мне было интересно, должен ли мой уровень обслуживания дублировать эти проверки?Если интерфейс уровня сервиса был представлен как веб-сервис, то я думаю, что проверка была бы хорошей идеей, но требуется ли это только в контексте веб-приложения?

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

Я вижу свои варианты как:

  1. Дублируем валидационные вызовы как в MVC, так и на уровне обслуживания
  2. Выполнять эту проверку только на уровне MVC
  3. Выполнять эту проверку только на уровне обслуживания.

Какая здесь лучшая практика?Я ищу советы / мнения о том, какой вариант мне следует использовать и почему.

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

Ответы [ 4 ]

5 голосов
/ 29 июня 2010

Не дублируйте код. Используйте JSR303 Bean Validation , чтобы вы могли использовать одинаковую логику проверки во всех слоях вашего приложения.

Hibernate Validator (отдельный проект от Hibernate ORM) обеспечивает эталонную реализацию этого интерфейса. Он очень прост в использовании, вы можете начать с ним очень быстро .

3 голосов
/ 29 июня 2010

По моему мнению, вам следует различать два вида проверок:

  • Проверка данных формата: которые должны быть проверены на уровне представления (MVC в вашем случае).Обычно как на стороне клиента, так и на стороне сервера
  • Проверка данных Bussines: что должно быть проверено на уровне обслуживания

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

1 голос
/ 29 июня 2010

Энни

Хороший вопрос, я задавал себе то же самое во многих случаях. Вот чем я закончил (до сих пор).

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

Я думаю, что нет ответа, который бы закончил все обсуждение. Я думаю, что это зависит от контекста вашего проекта. Если размер проекта скромный (с точки зрения количества людей и размера кодовой базы), и вы уверены, что не все разработчики разработают не так много кода, который вызывает API вашего сервиса (до такой степени, что вы не сможете его контролировать) ), тогда вполне может быть достаточно выполнить проверку только в веб-слое.

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

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

1 голос
/ 29 июня 2010
  1. В идеале, выполните проверку на обоих уровнях, поскольку ваш уровень обслуживания может использоваться с клиентом, отличным от текущего слоя mvc

  2. Повторное использование механизма проверкив обоих местах (например, проверка Бина)

...