Архитектура шовного приложения - PullRequest
2 голосов
/ 07 января 2010

Мне нужно реализовать довольно большую систему в Seam. Я обдумываю способ проектирования архитектуры. Если это хорошо использовать контроллеры страниц или контроллеры приложений или фронт-контроллер или каждый из них. Если полезно использовать бэкэнд-бин или нет необходимости делать это. Если у вас есть предложения или ссылки на полезные статьи, я буду признателен.

Большое спасибо!

Даниэль Микуки

Ответы [ 3 ]

1 голос
/ 11 января 2010

Daniel

Хорошей практикой является использование фронтального контроллера, большинство людей не знают об этом шаблоне проектирования.

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

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

Что касается контроллеров страниц / приложений, в Seam у вас есть больше контекстов или областей действия. Событие, Страница, Разговор, Сессия, Приложение, чтобы назвать большинство из них.

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

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

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

Ваше полное определение службы также может измениться. Для меня услуга - это поставщик услуг, такой как уведомление, безопасность (аудит), обработка исключений и т. Д. Все эти службы работают в фоновом режиме и не привязаны к определенному HTTP-запросу.

Walter

1 голос
/ 31 января 2010

Daniel

Я использовал один контроллер на страницу, один сервис и один дао на объект.

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

Хотя вышесказанное является хорошим и практичным подходом, в идеале:

  • Вы можете разбить любой не код MVC из контроллера в его собственный класс обслуживания, т.е. 1 класс обслуживания на страницу
  • Вы должны получить доступ к дао сущности только через службу сущностей.

Вот как будет проходить управление:

В идеале: UI -> PageController.java -> PageService.java -> EntityService.java -> EntityDao.java

Практически вы можете обрезать несколько слоев: Пользовательский интерфейс -> PageController.java -> EntityService.java

Или для действий, затрагивающих несколько объектов: Пользовательский интерфейс -> PageController.java -> Facade.java -> Entity1Service.java, Entity2Service.java

PageController.java будет @Component Seam, и в вашем пользовательском интерфейсе вы можете ссылаться на него как: #{pageController} и извлеките данные из представления.

В архитектуре самым важным является то, как вы размещаете вещи в стеке, избегая циклических зависимостей между слоями. Например, Entity Service не должен ссылаться на Controller и т. Д.

Другая важная вещь - это согласованность слоев во всем приложении. Используйте генераторы кода, если вы можете поддерживать согласованность кода в приложении, это действительно окупается для больших проектов. Посмотрите на Clickframes , если вы заинтересованы в генерации кода (Clickframes генерирует стартовый код для приложений Seam с полной поддержкой JPA / valdiation / security, которую вы затем можете изменить). Посмотрите эту демонстрацию Seam build с Clickframes, если интересно.

1 голос
/ 07 января 2010

Если вам нужно много узнать о Seam для проекта, я рекомендую вам получить книгу Seam In Action , которая является лучшей по данной теме.

Чтобы ответить на ваш вопрос, лично я предпочитаю использовать стиль pull-MVC в Seam, где вы ссылаетесь на данные в ваших шаблонах представлений, которые Seam по мере необходимости заботится об инициализации, используя @Factory методы. Однако в Seam существует более одного способа сделать это, поэтому стоит сначала прочитать об альтернативах, отсюда и рекомендация книги.

В качестве альтернативы, сначала создайте несколько приложений Seam, а затем попытайтесь создать одно «правильное»:)

...