Сервисный уровень JSF
Я не уверен, что мой подход к среде MVC в JSF - лучший путь. Поскольку я пытаюсь извлечь максимальную пользу из JSF, я хотел бы знать, как должен быть "разработан" мой уровень обслуживания (или модель, говоря в терминах MVC).
Я знаю, что соотношение View-Controller должно быть 1 к 1 (исключения исключены). Теперь, каким образом я должен спроектировать свой уровень обслуживания? Должен ли я использовать один большой сервис (так не думаю)? Если нет, на основании чего я должен разделить свои услуги?
Обратите внимание, что мой Сервис будет вызываться из Beans (контроллеров в терминах MVC), а сам Сервис будет вызывать DAO, используя JPA, когда это необходимо.
заранее спасибо
2 ответа
Уровень обслуживания (бизнес-модель) должен быть разработан вокруг основного объекта (модель данных). Например 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) недоступен в базовых контейнерах сервлетов, таких как Tomcat. Вам нужно установить, например, OpenEJB поверх него (или просто обновить до TomEE).
Независимо от выбора API уровня обслуживания лучше всего поддерживать методы прослушивания компонентов поддержки (JSF) JSF как можно более удобными, выполняя бизнес-задачу полностью на уровне службы. Обратите внимание, что сервисный уровень сам по себе не должен иметь каких-либо зависимостей JSF. Таким образом, любой (в) прямой импорт javax.faces.* в коде уровня сервиса указывает плохой дизайн. Вы должны хранить определенные строки кода в компоненте поддержки (обычно это код, который добавляет сообщение лиц в зависимости от результата вызова службы). Таким образом, сервисный уровень можно повторно использовать для других внешних интерфейсов, таких как JAX-RS или даже простых сервлетов.
Вы должны понимать, что основным преимуществом сервисного уровня в приложении Java EE является наличие управляемых контейнером транзакций. Один вызов метода сервиса на @Stateless EJB эффективно считается одной транзакцией БД. Поэтому, если исключение возникает во время одной из операций DAO, использующих @PersistenceContext EntityManager который вызывается вызовом метода службы, тогда будет выполнен полный откат. Таким образом, вы получите чистое состояние БД, а не грязное состояние БД, потому что, например, первый запрос на манипулирование БД завершился успешно, а второй - нет.
Смотрите также:
Соотношение 1:1 между сервисами и модельными объектами может быть неплохим, если в вашем приложении мало объектов. Но если это большое приложение, сервисов будет слишком много.
Количество услуг зависит от вариантов использования приложения, которое вы разрабатываете. После того как вы определили их на этапе анализа, вы должны сгруппировать их в несколько групп в соответствии с их функциональностью. Каждая группа вариантов использования будет Сервисом, и каждый вариант использования будет методом в этой службе. Каждая служба может управлять несколькими модельными объектами (и вам необходимо ввести в нее DAO, необходимые для выполнения ее функций). Обычно сценарии использования Сервиса управляют объектами модели, реализованными на диаграмме классов модели. Услуги могут следовать хорошей практике "максимальное сцепление / минимальное сцепление".
Соотношение между DAO и модельными объектами составляет 1:1. Каждый DAO выполняет CRUD-операции и запросы своего объекта. Если метод должен запросить 2 связанных объекта, поместите его в более подходящий DAO в зависимости от бизнес-концепций.
На уровне представления JSF у меня также нет соотношения 1:1 между страницами и контроллерами, это будет слишком много контроллеров. Я группирую в один контроллер все страницы, необходимые для выполнения сценариев использования каждого сервиса. Таким образом, соотношение 1:1 находится между контроллерами и сервисами, внедряя каждый сервис в контроллер, страницы которого выполняют свои сценарии использования.
Конечно, это общие принципы. У вас могут быть определенные случаи в приложении, которые их сломали, но их немного.
Возможно, у вас не будет слишком много служб и контроллеров, но не слишком мало, потому что тогда у них будет слишком много логики и полей. Вы должны достичь компромисса.