There weren't that many voices decrying EJBs, but since it's an
interesting subject I'll add my $0.02US:
EJB provides a way of abstracting business logic and persistence logic.
It does a pretty good job of doing the first. IMHO it does only an
adqueate job of doing the later. I have used EJB2.0 CMP for all of my
data access, and while it has provided me with RDBMS vendor
independance, it has some serious deficiencies:
. It's more complicated than writing your own data access layer. Maybe
this isn't supposed to be the case, but given the tools available now,
it's bloody difficult to create an entity bean layer without a *lot* of
learning. And you still have to know how the relational data store
works! I could have implemented my own persistence layer 5 times over
in the time it took me to figure out how to get CMP working correctly.
. It's difficult to optimize. When I ran my application against hsql
in server mode (so it spits the SQL out to the console) I was shocked at
how many queries were being issued. The way you structure your code
(calling finder methods, etc) has a serious and not necessarily obvious
impact on the SQL that gets generated. Even after rearranging a lot of
my code, I still see some rediculous iterative queries that I can't
explain.
. You can't model relationship attributes. This seems like a really
serious problem that I haven't found a good way around. Sure, I could
model the relationship itself as an entity, but that's hardly efficient.
. You still have to fallback to JDBC for many queries. Anything that
returns "joined data" is impossible to do with entity beans directly;
all you can ask for is objects.
I'm not antagonistic towards CMP; in fact, I will probably continue to
use it even on new projects. But if I had known up front how much
trouble it was going to be to learn, I probably would have taken a
different approach. If you don't have one or two EJB experts on the
team to start with, I wouldn't recommend building the data model with
entity beans. I still find myself tearing my hair out every now and
then.
Maybe this will change after another major revision or two... although
at Sun's rate, that'll be 2010.
Jeff
> -----Original Message-----
> From: Cory Updyke [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 27, 2001 10:05 AM
> To: Orion-Interest
> Subject: RE: MVC/XML Framework Comments please
>
>
> This may be off topic a little, but I am a little
> disheartened to see so
> many people disregarding EJB when considering a internet application
> framework. If you disregard transactions (NotSupported), and
> follow a few
> simple patterns (see java.sun.com/j2ee) you basically are
> able to build a
> powerful resource engine, which also completely isolates your
> business logic
> from your presentation tier. Although, you
> may be able to argue (trust me, I have done it in the past)
> that a JavaBean
> hitting a database is the same thing as an EJB call, it is
> likely that you
> will be wrong. Unless you have a server in Denver, CO
> talking to a server
> in Australia (which very seldom happens) the amount of time
> saved by having
> your
> resources (instance pools, db pools, jndi references, rmi
> pools, whatever
> else you can dream up) cached in the EJB server (even with
> RMI overhead),
> will blow the time it takes to make a DB request away. If
> you question
> this, run some tests. I have attempted to beat EJB
> performance by using a
> small self contained library a million times, and have seldom
> succeeded. I
> would recommend, unless your project is exceptionally simple,
> that a simple
> EJB logic abstraction is a valid consideration for the project.
>
> Back to the conversation.
>
> All of the recommendations for the web tier I believe are
> good, and come
> from years of development headaches that I am sure everybody has
> experienced.
>
> In reference to the web tier, the question that comes to mind
> when following
> this thread, is what are the needs of the system that is to
> be built. On
> one hand maintence is very important, but on the other hand, every
> abstraction hits performance. On one hand abstraction of
> content using XML
> is one of the most flexible ways to develop an internet application
> framework, but on the other hand, does your
> login page really need to be represented as an XML entity.
> Furthermore, is
> an additional transformation layer (cached or not) really
> worth it in terms
> of maintanence, performance, etc.
>
> I guess my point is, I have never found a global approach to
> data/presentation abstraction which I wasn't required to violate for a
> specific case. In fact, I have usually found that when
> approaching (an
> attempting to select) an architecture I often think "this is
> too complex
> from my needs," only later to find that I needed most of what
> it had to
> offer and just didn't know it at the time (and had to build
> it myself in the
> long run).
>
> My issue with XML/XSL transformations is this: My theory for the
> presentation tier is to keep it as simple as possible.
> Occasionally, you
> find a designer who has every right to be a engineer, but
> designs because
> they enjoy it. This person will scoff(sp?) at the simplicity
> of XSL. Most
> of the time you will find designers who know HTML (PDF, etc.). Which
> concept is closer to HTML, XML/XSL or JSP? I think JSP. I
> also have found
> it easier to say "Do you see the green (or whatever color
> depending upon
> your IDE) colored text? Please don't delete that" than it is to teach
> someone the concept behind XSL. You can have a good hour
> conversation, hand
> them the JSP Syntax Reference document and say DESIGN good man.
>
> Anyway... enough talk... we use Struts and our own Model-2-Brew.
>
> Cory
>
>
>
>
>
>
>
>
>
>
