Seam application Architecture

Question

I need to implement quite big system in Seam. I'm considering the way of designing the architecture. If it's good to use page controllers or application controllers or front controller or every each of them. If it's helpful to use backend bean or maybe there's no need to do that. If you have any suggestion or link to helpful article I will appreciate it.

Thanks a lot!

Daniel Mikucki

Answer 1

If you need to learn a lot about Seam for a project, I recommend you get the Seam In Action book, which is the best on the subject.

To answer your question, personally I prefer to use the pull-MVC style in Seam, where you refer to data in your view templates that Seam takes care of initialising, as needed, using @Factory methods. However, there is more than one way to do it in Seam, so it is worth reading about the alternatives first, hence the book recommendation.

Alternatively, build a few Seam applications first to throw away before you try to build one 'right' :)

Answer 2

Daniel,

It is good practice to use a front controller, most people aren't aware of that design pattern.

It is a really good design pattern to use because it ensures you are accessing the application through a single entry point. You can monitor everything that comes and goes easily with less configuration. You reduce the amount of possible code duplication because there is a single entry point. In addition to having less code to maintain, the code should be easier to follow since there is only one way in. You can then easily follow the execution flow of the application.

Unfortunately for Seam, there isn't really a front controller pattern. I haven't spent as much time as I would like to develop my own, but security and audit-ability are my number one focus.

As far as page / application controllers go, in Seam, you have more contexts or scopes available. Event, Page, Conversation, Session, Application, to name most of them.

If you're developing a controller or in Seam, a page action, most of the time, it will be event based. That is the shortest lived scope. If you have page flows, you would then use conversational-scoped components.

Take a look at the examples in the source code. You can do a lot with very little code, it is amazing, but at the same time, there is a lot going on that may take a while to pick up on.

The n-tier design that most places follow doesn't necessarily apply here. For most of my pages, I define a query that I'll use in XML (entity query), then I'll inject it into my page action and call it there. So instead of having a controller, service, dao, and entity classes, you end up with simply a page action, the queries, and entity classes. You can cut out the service and dao layers in most cases.

Your whole definition of a service might change too. For me, a service is a service provider such as notification, security (auditing), exception handling, etc. all of these services run in the background and are not tied to a particular http request.

Walter

Answer 3

Daniel,

I have used one controller per page, one service and one dao per entity.

• Use case logic goes in the controller
• Entity specific business logic goes in entity service.
• Actions which span multiple entities you can create a facade service - something which sits between controller and entity services

While the above is a good and practical approach, ideally:

• you could break out any non MVC code from controller into its own service class, ie. 1 service class per page
• you should only access the entity dao via the entity service.

Here's how the control would flow:

Ideally: UI -> PageController.java -> PageService.java -> EntityService.java -> EntityDao.java

Practically, you could trim down a few layers: UI -> PageController.java -> EntityService.java

Or for actions touching multiple entities: UI -> PageController.java -> Facade.java -> Entity1Service.java,Entity2Service.java

PageController.java would be a Seam @Component and in your ui you can refer it as: #{pageController} and pull the data from the view.

In architecture, the most important thing is how you layer things in the stack is avoid circular dependencies between layers. For example, Entity Service should not reference Controller and so on.

The other important thing is to be consistent about layering in the entire application. Use code generators if you can to keep your code consistent across the application, it really pays off for large projects. Look into Clickframes if you are interested in code generation (Clickframes generates starter code for Seam apps with full JPA/valdiation/security support which you can then modify). See this Seam demo build with Clickframes if interested.