Является ли проверка формы и проверка бизнеса слишком сложной задачей?

Подход, который вы описываете, кажется мне немного чрезмерным. Я вижу, что теоретически это аккуратно и чисто, но мне кажется, что было бы слишком гранулярно отображать данные в практической ситуации, создавая ненужные накладные расходы и множество классов, которые очень мало делают в общей схеме. вещи. Когда я сталкиваюсь с подобными вещами, это начинает немного пахнуть Solution Sprawl. Кроме того, если у вас есть много оболочек для каждого поля вокруг примитивов, у вас есть довольно хорошие шансы на нарушения DRY между вашим классом «AddressLine1» и вашим классом «AddressLine2» и т. д. или слишком сложная иерархия наследования, необходимая для их избежать.

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

• Проверка формы (на стороне клиента) на самом деле предназначена только для удобства использования.
• Проверка бизнеса — это настоящая проверка

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

Хотя кажется, что принцип DRY нарушается, на самом деле вы проверяете данные на двух разных уровнях — представления и бизнеса; проблемы проверки могут различаться между этими двумя уровнями. На уровне представления вас могут интересовать определенные элементы, связанные с вашим представлением, т. е. в веб-приложении вам может потребоваться вернуть определенное сообщение проверки, содержащее html div, чтобы вы могли правильно отображать ответ ajax.

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

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

Если вы также используете объекты бизнес-домена для проверки формы, что может быть достигнуто с помощью довольно простых инструментов, это устраняет недостатки большинства решений, основанных на валидаторе. В некотором смысле вы хотите экстраполировать частичное поведение из области бизнеса в область формы; это должно уменьшить код и улучшить обслуживание за счет дополнительной проводки. Я согласен с Робертом. Я чувствую, что этот подход лучше, чем Zend/Cake/Ci и т. д. Кажется, что он идет в направлении философии обнаженных объектов; просто сбросьте V и C, используйте только модели: http://en.wikipedia.org/wiki/Naked_objects

В Интернете вам, вероятно, нужна какая-то проверка на стороне клиента в качестве «первого входа» — проверьте необходимые значения и другие простые правила проверки, не требуя от пользователя выполнения веб-запроса только для того, чтобы убедиться, что данные недействительны. Кроме того, вам нужен слой проверки на стороне сервера (либо встроенный в объекты домена, либо в уровень службы, либо где-то еще), который выполняет фактическую проверку свойств объекта и других бизнес-правил.
Однако обратите внимание: что правила проверки, зависящие от домена (например, что Name имеет требуемые свойства FirstName и LastName) и чистые бизнес-правила (например, если было предоставлено State, Country должно быть USA) не обязательно должны находиться в одном и том же месте.

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