Правильное использование Beans в Java MVC

Question

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

Мой проект небольшой, веб-приложение на javaee, содержащее всего несколько сервлетов, соответствует дизайну MVC и использует bean-компоненты в качестве модели. Моя проблема в том, что мои бобы чаще всего являются «местом, где можно что-то наклеить, чтобы я мог получить приличный код». У меня сложилось впечатление, что bean-компоненты, конечно, были просто контейнерами для данных, но они также имели некоторую переносимость и полезность помимо одного сервлета.

Моя проблема - просто результат относительно простого кода или я, вероятно, неправильно использую концепцию бина?

Answer 1

Бины предназначены для хранения данных. Мы говорим о бобах Pojo. Если коллекций недостаточно для обработки модели данных, с которой работает приложение, создается класс, который соответствует потребностям. BEAN следует рассматривать просто как объект для временного сохранения состояния, имеющий сеттеры и геттеры, которые могут иметь легкую дополнительную функциональность. Нет ничего плохого в том, что ваше приложение работает с большим количеством компонентов, если вы придерживаетесь таких парадигм, как наследование и полиморфизм.

Pojo Beans также фиксирует модель данных (модель предметной области) вашего приложения, если оно выполняется в базе данных ... таблицы базы данных и компоненты соответствуют друг другу. Вот как работает ORM (сохранение состояния компонента во времени и наоборот). Даже без ORM уровень объектов доступа к домену хорошо работает на многослойной модели домена.

Они также являются лучшим способом просмотра презентации. Смешивая их с коллекциями. Реализация компараторов.

Термин «bean» начал использоваться, например, в среде Spring, где это просто класс, являющийся частью контекста приложения / контейнера Spring, а не JavaBean-метод получения / установки.