Зачем использовать шаблон фасада в EJB?

#ejb #facade

#ejb #фасад

Вопрос:

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

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

Верно ли приведенное выше утверждение?

Ответ №1:

  • Избегая тесной связи между клиентом и бизнес-объектами, повышая управляемость.
  • Сокращение детализированных вызовов методов приводит к минимизации вызовов вызова методов по сети, предоставляя клиентам детализированный доступ.
  • Может иметь централизованные ограничения безопасности и транзакций.
  • Большая гибкость и способность справляться с изменениями.
  • Предоставление только необходимого и предоставление клиентам более простого интерфейса, скрывающего основную сложность и внутренние детали, взаимозависимости между бизнес-компонентами.

Ответ №2:

Статья, которую вы цитируете, ПОЛНОСТЬЮ устарела. Проверьте дату, это 2002 год.

В EJB больше нет такого понятия, как entity bean (в настоящее время они сохранены для обратной совместимости, но находятся на грани полной очистки). Компоненты объекта, в которых возникают неудобства; объект модели (например, Person), который полностью находится в контейнере и для доступа к каждому его свойству (например, getName, getAge) требуется удаленный вызов контейнера.

В наше время у нас есть объекты JPA, которые являются POJO и содержат только данные. Не путайте объект JPA с этим древним компонентом EJB entity bean. Они звучат похоже, но это совершенно разные вещи. Объекты JPA можно безопасно отправлять (удаленному) клиенту. Если вы действительно обеспокоены тем, что имена, используемые в вашей сущности, раскрывают структуру вашей БД, вы могли бы использовать файлы сопоставления XML вместо аннотаций и использовать совершенно другие имена.

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

Комментарии:

1. однако идея шаблона фасада все еще актуальна, или теперь она также отличается? Потому что даже статья, которую вы найдете на сайте Oracles, датирована 2002 годом.

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

3. тогда статья не полностью устарела.

4. Хорошо, если вы читаете это ради концепции фасада, конечно. Он не устарел. Люди в 2090 году, вероятно, все еще могут прочитать статью об этом. Однако, как я упоминал, то, что, по-видимому, является основной мотивацией статьи, — это использование фасада специально для компонентов сущности. это устарело. Мне кажется, что статья не является общей статьей об объяснении шаблона фасада, но если это для вас, наслаждайтесь этим 😉

Ответ №3:

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

Ответ №4:

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