Validating values ​​confusion

Question

Я использую шаблон хранилища в сочетании с шаблоном спецификации, чтобы взаимодействовать с веб-сервисом (я предпочитаю репозиторий над DAO): как предлагает эта ссылка: http://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/.

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

Я запутанную alitte, конечная точка веб-службы принимают значения, но она не принимает отрицательных чисел, и я объявляю его как int и там не unsigned int в Java, так что теперь это хорошо, чтобы проверить для достоверности значений внутри каждой спецификации до того, как эта спецификация сделает запрос (потому что я уже знаю, что он потерпит неудачу) или только внутри сервисов !!! !!! я думаю, что каждая спецификация проверяет, что она ценит ее лучше, потому что я обязываю каждую службу, использующую эту спецификацию, справляться с этой проверкой, также как и я могу избежать дублирования кода, если каждая спецификация не делает проверку, и пусть служба делает это для него, проверка будет дублироваться в каждой службе, что мне кажется, плохо для повторного использования кода.

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

Я все равно смущен о SRP (принцип единой ответственности), делая это, каждая спецификация соответствует SRP ?? !!!! (у меня всегда есть проблемы с SRP, я не могу точно определить, каковы обязанности каждого класса в системе).

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

, если я делаю это в falsy образом, если there'e еще лучший способ или что-нибудь, пожалуйста, дайте мне теперь :)

Answer 1

Вы можете сделать проверку в любом месте вы хотите, однако, в зависимости от того, где вы положили его валидация играет другую роль:

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

В любом случае, любая проверка пользовательских данных должна обрабатываться в идеальном мире до того, как контроллер переадресует запрос на услугу. Если вам нужно запретить ввод «-1» - он должен быть здесь. Если человек вводит «abc» в текстовое поле - снова здесь. И так далее.

Услуги - ориентированные на домен. Они должны проверить, может ли задание, которое они заданы, выполнить с данными. Однако, если нет, они должны быстро сменить какой-то вызов assert или выбросить исключение во время выполнения. Они не должны предоставлять список хороших ошибок о том, почему они потерпели неудачу (если только для целей аудита). Любые данные, которые они выдают, уже должны покрываться предыдущими объектами (контроллерами, валидаторами и т. Д.). Единственное, о чем заботятся службы - если операция, о которой они просят, разрешена бизнес-правилами.

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

Иногда проверка уровня обслуживания не соответствует проверке в контроллере. Представьте сценарий в каком-то проекте, где постоянному пользователю разрешено вводить положительные значения, тогда как администратор может вводить и отрицательные. Ни один из них не может войти в «0» по какой-то причине бизнес-логики. Валидация "является отрицательной величиной & & Может ли текущий пользователь вводить отрицательные значения" будет находиться в контроллере. Валидация «равно нулю» будет также находиться в контроллере. У службы будет только «исключение исключения», если значение равно нулю или просто «значение утверждения не равно нулю», так как с его точки зрения он может завершить запрос с положительными и отрицательными.

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

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

---

Другими словами:

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

Итак, каков бы ни был ваш сценарий, подумайте о том, какие ограничения верны, и соответствующим образом организуйте свою проверку.