2010-01-07 3 views
2

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

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

Daniel Mikucki

ответ

1

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

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

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

1

Даниил,

Это хорошая практика, чтобы использовать фронт-контроллер, большинство людей Арен» t знал об этом шаблоне проектирования.

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

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

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

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

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

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

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

Walter

1

Daniel,

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

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

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

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

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

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

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

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

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

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

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

Смежные вопросы