2013-05-06 6 views
5

Я пишу веб-сервис.В каком слое должна выполняться проверка?

Обычно ввод будет XML-документом и выходным XML или JSON.

Приложения использует скороговорку MVC, имеющей различные слои

  • Контроллеры: Получение XML и предоставляют ответ (XML/JSON)
  • Услуги: Бизнес-логику, операции
  • DAO: Запрос источника данных (база данных или, возможно, другая веб-служба)

Мое понимание заключается в том, что базовая проверка (то есть: XML против XSD) должна выполняться как можно скорее на уровне контроллера.

После этого мне еще нужно выполнить дополнительные проверки, некоторые из таких проверок являются основными, например

  • Формат даты должен быть правильным
  • Имя пользователя не может превышать X символов (возможно также быть выполнены на XSD?)

Насколько я понимаю, такие базовые проверки должны были быть выполнены при развязывании XML в объект Java. Это также случились в слое контроллера (хотя сама проверка будет сделана объектом Java, где XML является unmarshalled в)

И, наконец, я сталкиваюсь с более «сложными» Validations примеров

  • дата не должна быть до 1950 (просто случайный пример)
  • Если значение А больше, чем в, то величина с не должна превышать D

такой «комплекс» valiations, кажется, за fect кандидат для интерфейса javax.validation.Validator. И также чувствует, что они должны выполняться на уровне контроллера.

Вопросы

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

Для меня ваша так называемая «сложная» проверка звучит скорее как необходимость бизнеса и как таковая должна быть поставлена ​​на уровень бизнес-логики. – mawia

+0

@mawia Хорошая точка, и, слава богу, я процитировал слово «сложный» :) –

ответ

2

Этот подход правильный? Должен ли я также проверять что-то на других уровнях?

Да, частично. Кажется правильным исправить входные данные для правильности, такие как формат даты, длина и т. Д. Нет необходимости выталкивать их во внутренние слои. Они должны быть проверены заранее.

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

Я добавляю слишком много логики в контроллеры? Должен ли я переносить некоторую проверку на уровень службы, где существует бизнес-логика?

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

Как упомянуто выше, на уровне обслуживания должны быть реализованы некоторые проверки, которые следуют бизнес-правилам.

Edit: Как вы добавили веб-сервис тегов, представьте, что вы вызываете веб-службу & затем на стороне сервера, это стало известно, что данные имеют неправильную форму. Возможно, это было сохранено в оба конца, время сервера, сетевой ресурс и т. Д., Если оно было проверено ранее.

+0

Скажем, мне нужно подтвердить, что имя пользователя не должно превышать 15 символов, и оно должно быть уникальным. Ограничение на 15 символов произойдет в контроллере, и проверка уникальности произойдет на уровне службы/бизнеса? – Aquillo

+1

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

+0

Хорошо спасибо за подтверждение моего подхода :) – Aquillo

Смежные вопросы