Я чувствую себя немного конфликтовавшим в данный момент. У меня есть веб-приложение с помощью Дорожек для платформы MVC и Spring/Быть в спящем режиме для бэкенда. У меня есть метод регистрации аккаунта в моем уровне MVC, который требует следующей проверки:
У меня есть метод проверки в Дорожках (уровень MVC), который проверяет эти два случая, но задавался вопросом, должен ли мой уровень служб копировать эти проверки? Если бы интерфейс уровня служб был выставлен как веб-сервис затем, я думаю, что проверка была бы хорошей идеей, но если это используется только в контексте веб-приложения, требуемый?
Править: Я не намереваюсь копировать код доступа - я означаю копировать вызовы метода проверки в двух местах.
Я вижу свои опции как:
Что такое лучшая практика здесь? Я ищу совет/мнения, на которой опции я должен пойти с и почему.
Обратите внимание, что существует простая проверка, проверяет поля ввода формы регистрации (как проверка пробелы) и что я думаю, что они должны быть обработаны проверкой MVC только; я только обеспокоен более сложными проверками.
Энни,
Хороший вопрос, я задавал себе то же самое много раз. Вот что у меня получилось (до сих пор).
Самый чистый (но утомительный) подход - задействовать логику проверки на обоих уровнях. прагматический подход может заключаться в том, чтобы вызывать его только в веб-пространстве (например, ваших контроллерах).
Я думаю, что нет ответа, который положит конец всей дискуссии. Думаю, это зависит от контекста вашего проекта. Если размер проекта невелик (с точки зрения людей и размера кодовой базы), и вы уверены, что не весь код будет разработан другими, которые используют ваш сервисный API (до такой степени, что вы не сможете контролировать ), тогда может быть достаточно выполнения проверки только на веб-уровне.
Однако, если вы ожидаете много клиентов, вам может потребоваться более высокий уровень безопасности. Когда я говорю здесь о безопасности, я имею в виду необходимый вам уровень согласованности.Если этот уровень высок, выхода нет: вам придется делать это как в сервисе (для безопасности), так и на веб-уровне (в основном, чтобы иметь возможность предоставить конечным пользователям приемлемый опыт).
Таким образом, ключевым фактором здесь является безопасность и то, сколько из них вам действительно нужно. Если вам нужно много, вы выбираете «пуристский» подход. Если ваше приложение не совсем точно принимает решения, касающиеся жизни и смерти, вы выбираете прагматический подход.
На мой взгляд, вам следует различать два типа проверки:
В вашем случае ваши проверки связаны с бизнес-правилами, поэтому я помещу их только на уровень обслуживания. Кроме того, если вы дублируете свои проверки на обоих уровнях, вы будете делать одни и те же запросы дважды, что снизит производительность вашего приложения.
Не дублируйте код. Используйте JSR303 Bean Validation , чтобы вы могли использовать одну и ту же логику проверки на всех уровнях вашего приложения.
Hibernate Validator (отдельный проект от Hibernate ORM) предоставляет эталонную реализацию этого интерфейса. Он чрезвычайно прост в использовании, вы можете начать с ним очень быстро .
В идеале, выполняйте проверку на обоих уровнях, так как ваш уровень обслуживания может использоваться с клиентом, отличным от текущего уровня mvc
. пример)