Seam Design Patterns

[flsusp.fabio.dextra-sw.com]

I have tried Seam for 2 months and I have a lot of design pattern questions and doubts on the better ways for configuring my applications. The fact is I'm not secure about the better design to use when using Seam. The use of statefull beans is ok and is very, very good. But the coupling of the web and the ejb tiers is very hard to keep. I know that it is, probably, a very common problem and I hope there is some design patterns and best practices that the comunity have experienced and that I can try here too. But, where do I find it?

My newcommer questions are:

1) How much complexity I must put on a single stateful bean? On other words, is better to use a single stateful bean for a long running conversation or use several beans instead?

2) I become very happy when I didn't see any Java classes on my web tier (only JSF converters and validators). But, the coupling to the ejb tier becomes annoying. Is this a good practice? On other words, to use annotations like @DataModel and to put navigation specific methods on the ejb tier is a good practice? Even in hard scalability and performance systems?

Thanks for the help and sorry for my terrible english...

Fábio.

[pmuir]

Fábio Santos wrote on Feb 21, 2008 07:19 PM:


1) How much complexity I must put on a single stateful bean? On other words, is better to use a single stateful bean for a long running conversation or use several beans instead?

I would use both designs, depending on the complexity of the conversation. Start simple, add more beans if you need them or need to factor out common functionality.

2) I become very happy when I didn't see any Java classes on my web tier (only JSF converters and validators). But, the coupling to the ejb tier becomes annoying. Is this a good practice? On other words, to use annotations like @DataModel and to put navigation specific methods on the ejb tier is a good practice?

I personally would avoid this coupling:

• Use EntityQuery and do #{myQuery.dataModel}, or do something similar with a base class of your own.


• Use navigation rules in pages.xml with rules that inspect the state of your bean, rather than logical outcomes.