BTW - although Seam is made to work with EJB3 or just Hibernate, there is no need for either. You can use POJOs for entities and application beans and just use straight JDBC in your action methods to save the data. Seam uses annotations, but they are not the same annotations as EJB3 (it just happens that all of their examples use EJB3 and/or hibernate annotations). I am running with no EJB3 at all with seam without issue. My action beans are POJOs and my data store beans are POJOs with hbm.xml mapping files. I just use seam annotations of @Factory, @Name, @In, @Out, @Valid, etc.

Just wanted to make sure this was clear in case someone wanted to use seam but didn't want EJB3 and/or hibernate.

-Andrew

On 1/16/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
On Mon, 2006-01-16 at 20:56 +0100, Werner Punz wrote:
> Well seam basically is JSF interwoven with EJB3, the thing is, basically
> every session bean becomes automatically a backend bean, so you program
> the entire backend code all three tiers in EJB3. If you do not like that
> stay away.

A developer at my most recent client had done an evaluation of Seam, and
rejected it due to this point. According to him, presentation logic ends
up in EJB stateless session beans.

This isn't necessarily bad for small projects; J2EE has always been
massively overcomplicated for projects of the size of a few weeks
development.

However proper separation of presentation and business logic is critical
for larger projects.


> Also using ejb3 entity beans is implicitly forced upon you because you
> get all the benefits automatically, like injection of the entity
> manager, transactional handling.

Yes, but EJB3 persistence rocks. It's basically a standardisation of
Hibernate/TopLink so is well tested in the real world. If you've got a
relational database as the persistent data store, why would you use
anything else?

EJB3 session beans are also massively improved over prior versions of
EJB; finally I think they've got it right.

> There are millions of ways to combine things, that is a huge strength in
> the JSF world, the people who did the standardization by far did not a
> perfect standard, but it is very good in being open, alterable and
> expendable.

Agreed! The best combinations can now fight it out; it will be a while
before the best solution becomes clear. However the flexibility of JSF
makes this possible. [BTW, I hope you meant "extendable", not
"expendable" :-]

Regards,

Simon


Reply via email to