Hi,
I think I might add our 2c, even though they are completely against the
trend ;). In fact, we don't use EJBs at all, unsing instead Stored
Procedures to perform the business logic. When we started, EJB was an,
IMHO, inmature technology that forced people to write lots of
intermediate classes to get to the point, it forced you to write vendor
dependent code, it had a "everything is remote" philosophy that was
pretty inconvenient and good god! it didn't even took into account
relationships between tables! After testing EJB with some projects, we
dropped it because the tediousness of typing so much code, the need to
write embedded SQL or use vendor dependent features and the development
cycle of using EJB, which we don't actually enjoy. We ended up using
XML, and even though we can generate it from anything that we please
(action classes, JSP, even EJB, if we please) we use, most of the time,
stored procedures to generate it. Why? Because it's the place closest to
the database, so it "travels" with it, you have compile-time
dependencies between your code and the database schema and you have the
appropriate tools to acces/manipulate the database. In case we want/need
to do some special pre-/post-processing, then Java comes to the rescue
and it is used to further refine the request/response. Besides, that
means our business logic, based on XML, is independent of ever changing
standards and interfaces. We are quite happy with it, and it has also
allowed us to divide the work pretty nicely, as I have had some people
working on the project, programming the business logic, who didn't know
a single word about Java, HTML or the like. And our designer doesn't
know what is a table, a bean, the context or anything like that.
Warning!! I'm not saying that this is a universal solution and that EJB
should be dropped. No. I'm just saying that they are not the only
solution and that sometimes, for example in our case, using stored
procedures is better for our overall development. We know we might lose
some performance in some cases, but we prefer the easiness of
development and the independence of our code.
Just my 2c,
D.
PD: I follow the EJB spec anyway, and I know EJB2.0 solves partially
some issues that where some of the reasons why we dropped it, but I for
us it's still too little to late.
