Является ли проверка форм и бизнес-проверок слишком большой?

Question

У меня есть вопрос о проверке формы и проверке бизнеса. Я вижу много фреймворков, которые используют какую-то библиотеку проверки формы. Вы отправляете некоторые значения, и библиотека проверяет значения из формы. Если не в порядке, он покажет некоторые ошибки на вашем экране. Если все пойдет по плану, значения будут установлены в доменные объекты. Здесь значения будут или, лучше сказать, должны быть проверены (снова). Скорее всего, такая же проверка в библиотеке проверки. Я знаю 2 PHP-фреймворка, имеющих такую ​​конструкцию Zend / Kohana.

Когда я смотрю на программирование и некоторые принципы, такие как Не повторяй себя (СУХОЙ) и принцип единой ответственности (SRP) это не очень хороший способ. Как видите, это подтверждается дважды. Почему бы не создать объекты домена, которые выполняют фактическую проверку.

Пример: форма с именем пользователя и адресом электронной почты Форма отправлена. Значения поля имени пользователя и поля электронной почты будут заполнены в 2 разных объектах домена: имя пользователя и адрес электронной почты

class Username {}
class Email {}

Эти объекты проверяют свои данные и, если они недействительны, выдают исключение. Ты согласен? Что вы думаете об этом подходе? Есть ли лучший способ реализовать проверки? Я запутался в том, что многие фреймворки / разработчики занимаются этим. Они все не правы или я упускаю точку?

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

Answer 1

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

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

Answer 2

Хотя кажется, что принцип СУХОГО нарушается, вы фактически проверяете данные на двух разных уровнях - представление и бизнес; Проблемы проверки могут различаться между этими двумя уровнями. На уровне представления вы можете быть обеспокоены конкретными элементами, связанными с вашим представлением, т. Е. В веб-приложении вам может потребоваться вернуть специальное сообщение проверки, содержащее HTML-элемент div, чтобы вы могли правильно обработать ответ ajax.

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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