Правильное использование bean-компонентов в Java MVC

Question

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

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

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

Answer 1

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

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

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

Термин «bean» начал использоваться, например, в Spring Framework, где он является просто классом, который является частью контекста приложения/Spring-контейнером, и не является вообще-то Java-компонентом getter/setter.