#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.
Конечно, это скрывает структуру данных от «неизвестных» приложений, если вы предоставляете свои компоненты внешним сетям