Spring formBackingObject, создание бизнес-объектов и фабрики

Question

Вопрос проектирования для использования бизнес-объектов в качестве formBackingObjects в Spring SimpleFormController.

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

Итак, мы передаем наш бизнес-объект через метод formBackingObject (запрос HttpServletRequest). Однако мы столкнулись с загадкой.

Фабрика, которую мы используем для создания нашего нового бизнес-объекта, применяет бизнес-правила, согласно которым некоторые атрибуты не могут быть нулевыми. Но поскольку мы не знаем, что хочет ввести Конечный пользователь, мы передаем «разумные значения по умолчанию», такие как «Пожалуйста, введите желаемое имя», но в лучшем случае это выглядит как хаки / icky.

Что делать разработчику? Я чувствую, как будто это классическая проблема курица / яйцо.

Все наши бизнес-объекты основаны на интерфейсах. Должны ли мы создать заглушку, которая представляет бизнес-объект, передать заглушку как formBackingObject, а затем передать заглушку фабрике при отправке формы? Или мы не должны ничего передавать в формеBackingObject, а затем вручную собирать предоставленную информацию из запроса?

Есть ли другие разумные идеи / закономерности?

Спасибо за ваше время.

Answer 1

Я бы точно не выбрал вариант не использовать formBackingObject и собирать информацию вручную - это исключило бы большую часть возможностей, которые делают Spring MVC стоящим в первую очередь.

На вашем месте я бы просто создал новую фабрику или фабричный метод, специально предназначенный для создания "неинициализированного" бизнес-объекта, и использовал бы его в качестве своего formBackingObject.

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

Answer 2

Используйте объект команды (очень простой POJO) для представления ввода пользователя в ваш контроллер. Затем вы можете использовать встроенную проверку в Spring MVC, чтобы убедиться, что все обязательные поля предоставлены в объекте команды. Если команда проходит проверку, вы можете программно сопоставить ее с вашим «Бизнес-объектом» (или использовать библиотеку сопоставления компонентов, например Dozer ).

Таким образом, вы можете обрабатывать проверки, неполные пользовательские представления и т. Д., Не затрагивая или не изменяя существующие бизнес-логики / правила / классы обслуживания. Это позволяет вам отделить веб-слой от этих существующих слоев.

Для справки см. учебник MVC , в котором рассматриваются объекты проверки и команды в Часть 4 .