Уровень обслуживания JSF - программирование

Я не уверен, что мой подход с средой MVC в JSF - лучший способ. Поскольку я пытаюсь извлечь максимальную пользу из JSF, я хотел бы знать, как должен быть спроектирован мой сервисный уровень (или модель, говорящий на условиях MVC).

Я знаю, что отношение View-Controller должно быть от 1 до 1 (исключение исключено). Теперь, каким образом я должен создать свой сервисный уровень? Должен ли я использовать один большой сервис (не так ли)? Если нет, на основании чего я должен разделить свои услуги?

Обратите внимание: моя служба будет вызвана из Beans (контроллеры в условиях MVC), и сама служба вызовет DAO с помощью JPA, если это необходимо.

Ответы

Ответ 1

Уровень обслуживания (бизнес-модель) должен быть разработан вокруг основного объекта (модели данных). Например. UserService для User, ProductService для Product, OrderService для Order и т.д. У вас не должно быть ни одного огромного класса обслуживания. Это очень жесткое сцепление.

Что касается самого API уровня сервиса, Java EE 6 предлагает EJB 3.1 как API уровня сервиса. В темном возрасте J2EE, давным-давно, когда EJB 2.0 был страшно развиваться, Spring чаще использовался как API уровня сервиса. Некоторые из них по-прежнему используют его в настоящее время, но поскольку Java EE 6 содержит все полезные уроки, извлеченные из Spring, он стал лишним. Обратите внимание, что EJB (и JPA) недоступен в barebones servletcontainers, таких как Tomcat. Вам нужно будет установить, например, OpenEJB поверх него (или просто перейти на TomEE).

Независимо от выбора API сервисного уровня, лучше всего было бы поддерживать JSF-поддержку bean (действий) методов прослушивателя максимально возможной, выполняя бизнес-задачу целиком на уровне обслуживания. Обратите внимание, что сервисный уровень сам по себе не имеет какие-либо зависимости JSF. Таким образом, любой (в) прямой импорт javax.faces.* в коде уровня обслуживания указывает на плохой дизайн. Вы должны сохранить отдельные строки кода в базе bean (обычно это код, который добавляет сообщение лиц в зависимости от результата вызова службы). Таким образом, сервисный уровень повторно используется для других интерфейсов, таких как JAX-RS или даже простые сервлеты.

Вы должны понимать, что основным преимуществом уровня сервиса в приложении Java EE является доступность транзакций, управляемых контейнерами. Один вызов метода службы в @Stateless EJB эффективно учитывается как одна транзакция БД. Поэтому, если исключение возникает во время одного из любых операций DAO с использованием @PersistenceContext EntityManager, который вызывается вызовом метода службы, тогда будет завершен полный откат. Таким образом, вы получаете чистое состояние БД, а не грязное состояние БД, потому что, например, первый запрос манипуляции с БД преуспел, а второй нет.

См. также:

Ответ 2

Соотношение 1:1 между службами и объектами модели может быть неплохо, если в вашем приложении несколько объектов. Но если это большое приложение, будет слишком много сервисов.

Количество услуг зависит от вариантов использования приложения, которое вы разрабатываете. После того как вы определили их на этапе анализа, вы должны сгруппировать их в несколько групп в соответствии с их функциональными возможностями. Каждая группа вариантов использования будет Службой, и каждый вариант использования будет способом в этой службе. Каждая служба может управлять несколькими объектами модели (и вам нужно вводить в нее DAO, для чего она должна выполнять свою функциональность). Обычно случаи использования службы управляют объектами модели, которые реализуются в диаграмме классов модели. Услуги могут следовать хорошей практике "макс. Сцепления/мин".

Отношение между DAO и объектами модели составляет 1:1. Каждый DAO выполняет операции CRUD и запросы своего объекта. Если метод требует запроса 2 взаимосвязанных объектов, поместите его в более подходящий DAO в зависимости от бизнес-концепций.

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

Конечно, это общие принципы. У вас могут быть определенные случаи в приложении, которые их нарушили, но их немного.

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