you have some points for small projects but with a few caveats that apply even to the smallest and
most trival of projects.
1. Writing DAO style code and not leveraging it INSIDE you BMP EJB's as delegates
is BAD. It just creates more code to wade thru when a change to the data happens.
It makes you applications brittle and error prone and complicates tracking down any
errors that do creep in, because the data access code is strewn about the code tree
instead of inside a single component.
2. DAO style code is VERY heavy unless there is some form of caching of the objects and results
sets. Which Entity Beans do with no code involved. Adding this caching code is error prone and
most places that use Enity Beans are trying to solve some specific business problem in THEIR domain.
Not write generic object caching code, no matter how NEAT, is not their business strength. Here
read-only Entity Beans will out preform any DAO code if there are enough users asking for the same
data sets, it will get cached in the app server.
3. DAO style code can eat up database connections very quickly even using pooling, and as above
can become VERY "heavy" if over used. And very very very difficult to scale or tune. One place
I worked learned this the hard way.
4. Importing java.sql.* into places outside Entity or Session beans is BAD from every standpoint.
Servlets, JSP's, etc. should NEVER have to import anything from java.sql.*, if they do, it is bad
design.
With J2EE containers like with Java itself there are preformance trade offs for everything, personally I will trade off a few ms in remote calls and a few bytes of memory for ease of maintaince and future enhancements vs
a questionable performance gain that was probably caused by bad design to begin with. And 80% of all the money spent on a corporate project is in MAINTANCE time, NOT development time and NOT in hardware. And hardware is CHEAP and a write off anyway.
-----Original Message-----
From: Curt Smith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 20, 2001 8:55 AM
To: Orion-Interest
Subject: Re: Course Grained Entity Beans...your thoughts....
Maybe folks could comment on my thoughts?
- Most client traffic (web site etc) is read only. I.E. building pages
showing store
catalogue, browsing available plane seats etc etc. Why run read
only traffic
through architecture optimized for transactional robustness? That
is unless
you want to buy more hardware and deliver slow response for everyone.
- Given, the reality of traffic read VS write, I feel that highest
performance,
scalability and low latency will be from an architecture based on DAO for
read only operations from the client - business deligate tier. I.E.
from beans
called from JSP's directly.
- Allow the client tier business deligate methods to direct read only
traffic
to DAO's. Other methods that are transactional (CRUD), are directed to
session bean methods to mediate entity business logic. Local
interfaces would
speed these operations greatly!
- EJB 2.0 local interfaces and coarse grained beans will always eat CPU, RAM
and scalability, latency when compared to DAO for read only operations.
- Coarse grained beans can actually be a serious resource hog if you
don't implement
lazy instantiation of the dependant 1:M components. Else you'll be
hitting the DB
and building the 1:M objects when the "M" part isn't accessed.
- Does EJB 2.0 CMP for coarse grained beans implement lazy instantiation
of the
dependant compents?? If not, or your container vendor hasn't, watch
out??...
- The "new" best practice EJB architecture as of EJB 2.0, makes sense if
you're
architecting a shrink wrapped product that has to work with customer
supplied
DB's and schema's. I don't believe this is very common, nor will be.
So why are
the Sun J2EE blueprints showcasing this architecture? I don't know.
I'll be sticking with the architecture that's based on DAO and EJB for
transactions
only.
BTW, my thoughts on QL vs SQL... QL and CMP is just one more pain that
I see folks sinking bunches of time in. You need to own your data and
will end
up spending the same time needed to write DAOs and SQL anyway, so why
not do it?
curt
>
>
>I was reading the J2EE design patterns book and it suggested using a Course
>- grained approach at building your entity beans (dependent tables accessed
>via Data Access Objects). However, after inspecting the new 2.0 specs, and
>considering the inclusion of EJBLocalHome and EJBLocalObject, is it
>necessary to still follow this recommendation? I personally would rather not
>code DAOs, however, if there is a performance gain by doing so, I would.
>
>Thanks for you advice.
>Aaron.
>
