A good design pattern practice?

[mhdez]

I need to make a simple database application but I don´t know what design pattern to use. Please someone can suggest me a good design pattern practice for this common database application.

Thanks in advance!

[gonorrhea]

There are many basic design patterns that are used in Seam applications.  Two of these are MVC (model/view/controller) and DAO (data access object).  DTO (data transfer object) is now an anti-pattern as of EJB 3.

JSF has a MVC architecture.  DAO is sometimes useful if your app has a lot of business logic and persistence logic which needs to be abstracted into its own layer.  DAO is also good for component reusability and unit testing faciliation.

A good example of how to implement your code for a simple Seam CRUD app can be found in the hotel booking example.

basically, it's this: JSF (facelet) --> SFSB --> entity class.  You can substitute the SFSB with a conversation-scoped JavaBean (POJO) if you don't want to use EJB.

The real beauty of Seam app design/development is that you are not forced into using certain design patterns.  This was a major problem with the Struts/EJB2.x stack.

Additional useful Seam-specific design patterns are use of the @Factory (factory component pattern) + @DataModel/@DataModelSelection(Index) annotations, as well as the @Unwrap (manager component pattern).  @RaiseEvent and @Observer are useful as well.

Read the Seam ref docs for more info as well as the new Seam books.

[arshadm]

This is a good question, because I think it would help the adoption of seam if there were some design patterns for common scenarios (e.g. CRUD, master-detail CRUD, etc).

The seam booking example shows the technology is action, but as a software engineer I don't find the code to be well designed. This is not a criticism of the guys that wrote the booking example they were just showing off what the technology could do, but as somebody trying to learn and use seam in production it's mo model to adopt for your own code.

Even in the case of JSF (facelet) -> SFSB --> entity classes pattern, you have to ask what is a suitable structure for the SFSB and where should conversations (if any be used). Can a CRUD really be done with just one component without abusing or overusing @out for different purposes (e.g. one @Out for viewing and @Out for editing a bean).

I think Seam is a fantastic toolkit, it has so much functionality. But it would be great if brains larger than mine could apply themselves to some best practices (maybe Dan Allen should work on a Seam Patterns book).

[mhdez]

Thank you gentelmens...! That was a good help...

[gonorrhea]

The purpose of the Seam booking example is to demonstrate usage of conversation scope and workspaces in a simple CRUD app using templates via Facelets as well as live validation using Hibernate Validators, authentication, bijection, annotations, generics, transactions, etc.

It actually covers a lot of ground/functionality using HSQLDB as the back-end.  It is and most likely always will be the classic Seam learning/tutorial app.   It does take several months, honestly, to really master all the concepts and API/technologies in that single app.

As far as design patterns are concerned, DAO and Action classes, for example, are not enforced/required by the framework.  That's one of the beauties of the Seam fwk as layering is not enforced, it's up to the architect/developer to determine how much layering is necessary for a particular app.

Some of the old EJB2.x patterns, like session facade, are now anti-patterns or unnecessary.  You can directly reference and call get/set methods on entity classes (POJOs) in your JSF xhtml file while looping thru a ListDataModel that is outjected via @DataModel in your SFSB or JavaBean.  This was not possible before using Struts/EJB2.x b/c we needed the DTO pattern to transfer the entity bean data from the persistence layer to the presentation layer.

I doubt that a Seam Patterns book will be published but who knows...

[sashkanem]

I agree with Robert Burns, seam booking example shows the scalability and functionality of this excellent framework, but as software developer, I can say that it definitely can't be some kind of design example of real (not simple functional web-site) application.

We use seam in our enterprise applications, main part of our application is build upon standard java EE technologies (web services, scheduling, jboss services, monitoring, etc). we found seam + facelets + richfaces good combination for rapid presentation layer development. The main goal of using seam, was that it suggests simple ways to avoid old famous problems like Lazy Fetching. And seam gives you possibility of think more of design and functional ways and not spent much time on that kind of problems. Which in result gives much advanced productivity. Projects are built faster.

I found SESSION, PAGE and DEFAULT (none, scoped seam components mostly used in our applications, there are really very rare situations when you see that right that must be the CONVERSATION and I will look up my stateful EJB(DAO) use it with no doubt that persistence context will be alive and remove it in the end of conversation. However there are also some issues here like stateful bean passivation. And that it can be more appropriately configured in environment. Or for example synchronized excess restriction on stateful bean. Also in fact using seam upside down with all its functionality, often lead to poor performance (where @BypassInterceptors annotation helps us). And developer must be very attentive with memory leaks that usage of many stateful EJB beans can lead to.

Using stateful beans have many pros and cons, and it would be nice to read some articles on using stateful objects for presentation. With discussion of proper scopes and memory and concurrency issues. Also about automatic flushing, I know there is written about it in documentation, but without using CONVERSATION scope and flushMode set to MANUAL, it is very easy to get unintended result.

All in all besides some problems that I mentioned very briefly, seam is really step ahead other existing frameworks for rapid development, and thanks to all it's developers for the work that they have done.

I would be glad to hear other seam users ideas about this kind of problems. And discuss architecture practices that showed out in production

Thanks in advance.