..:: Questions about Seam design!!!

[angelogalvao]

First off all: Sorry for my english

Well , after a lot of in and out about Seam, JSF and EJB3 first experience development, now i'm using the 3 in a big, very big project...

But when i look some aspects of the design i think that's go against what i learned, i think... help me to clarify that issues.


Seam components seems to go against the 3 layered architecture... In the Seam examples the same bean save the object and make a query(DAO), put a message in a facesMessages (Controller) and make some bussiness validation and bussines proccess (bussines/service )... The problems that go with that everybody kwons. This architecture just works with a JSF, EJB3 and Seam technology.

Another think is that i have learned that a SessionBean must have the bussiness methods, for example, a doctor CRUD methods is in the DoctorManagerBean, but with Seam i put navigation a action listeners methods too and some others like for component binding, so my session bean is not reusable in another ambient...

I'm do that because is that way that i learn Seam. The examples works like that... But can i separete the corcerns? Seam support that? do i lost my conversations if i my state is held in a SFSB that Seam not managed?
What the best solution?


Again: Sorry for my english

[andre1001]

Hi Angelo,

do you have e-mail? I looking for Seam contacts in Brazil.

Thanks.

[angelogalvao]

"Andre1001" wrote:
Hi Angelo,

do you have e-mail? I looking for Seam contacts in Brazil.

Thanks.

[e-mail]

[bfo81]

Seam still uses a 3-layered architecture. Ok, it breaks with traditional J2EE patterns like DAOs and stuff. But hey, this is called "progress". You do not need this fat old architecture paradigmas. Keep your code small, simple and maintainable. Seam enables you to do so ;).

[jbmadair]

bfo81, if you'd like to use Seam with a separate back-end layer of any sort, it's quite easy to do so. Look at the CaveatEmptor CVS checkout from the Hibernate in Action book web site for nice generic DAO layer abstract classes if you're wanting to combine it with Hibernate.

I'd venture that you can pretty much always do without the DTO paradigm and just pass disconnected Hibernate entities back, even when you do want a DAO layer, perhaps excepting the case where you want a long-lasting API for published web services (for third parties).

I've had a lot of success so far working with a DAO layer, and in our case, a very large project that has a "business engine" that is accessed for multiple business lines and separate web-applications, it does seem appropriate and done right adds very little code overhead.

The best bit is that even with the layer in the back-end you can use components.xml to instantiate back-end entities and DAOs as Seam components in any scope without them having to have any Seam-specific coding.

[fhh]

Seam still uses a 3-layered architecture. Ok, it breaks with traditional J2EE patterns like DAOs and stuff. But hey, this is called "progress". You do not need this fat old architecture paradigmas.

But you can still use them if you want to. If it is necessary you can still have a session bean as a wrapper around the EntityManager. I sometimes use this pattern, if the retrieving of entities is more complex and does happen - at least sometimes - outside of seam. This is useful if you have MDBs and you don't want them to depend on seam so you can deploy them on another AppServer more easily.

Regards

fhh

[nicola9000]

Hiya ,
Yes, traditional tiers are a bit mixed.
You can have a "navigation tier" in a finder that is "data tier", like in booking example.

I am thinking much and i think that the architectural new solution is "Bijection based"
I am writing my finders and i inject in them presentation objects.
So my finders are "clean" and they still are "data tier"
And i have Presentation objects and pure business objects, like always.

So you can reuse your data tier components, place them in a separate project that generates only a .jar ( i am doing so ). You could create a complete .ear that will be a "data tier object server", but this solution should be well evaluated.

(Sorry for my English)

good work, Nicola

[gavin.king]

I don't know why everyone is saying you can't use DAOs .... you can absolutely use DAOs if you want! There is no problem at all, just write an @Stateless bean with @Name("customerDao") and inject it into your action handler.

It's just that you don't really need DAOs these days - they smell of overengineering....

[angelogalvao]

I don't know why everyone is saying you can't use DAOs .... you can absolutely use DAOs if you want! There is no problem at all, just write an @Stateless bean with @Name("customerDao") and inject it into your action handler.

It's just that you don't really need DAOs these days - they smell of overengineering....

I agree with you about about DAO's...

What i dont like is manipulate JSF components in the same method/Object that i save a entity for example...

[bfo81]

I didn't say you CANNOT use DAOs anymore. I just said you CAN leave them out (in many cases).

Look at the AppFuse framework (Spring + Hibernate):

- Entity class
- DAO interface
- DAO implementation
- Manager interface
- Manager implementation
- Backing bean for presentation layer

*dooooh*

Same in Seam:

- Entity class
- Controller local interface
- Controller stateful bean

Yes, of course, there are many special cases. When using huge shared databases or whatever, then use DAOs. But in many cases it's not necessary.

Be courageous and don't use patterns you don't need just because others use to use them ;).