We too tried to use a liteweight persistence layer (jrf) with a few
extensions, and found that Orion CMP was just as fast at most things, and
significantly faster at relationships. I originally felt we needed to
switch because some of our beans used bidirectional relationships
implemented as get methods wrapping a finder method. This led to a pretty
hefty performance hit. When Orion supports EJB QL and n:m relationships
(1.5.0?), I think that performance issue will be lessoned. Until then, we
had to denormalize our db a little while still use CMP.
While looking at the various MVC frameworks, we too couldn't find anything
to meet our needs. Struts and webWork were significantly more difficult to
learn, which conflicted with the idea of making JSP easier for web
designers, IMHO. Freemarker looked good until I found you had to write an
adapter for each bean you wanted to expose for their template engine.
We ended up writing our own MVC framework because of the unique requirements
of our ASP based project. About 50% finished, we have been very pleased
with our choice of Orion and CMP.
Michael Third
Parts.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker
Sent: Friday, April 27, 2001 2:12 PM
To: Orion-Interest
Subject: RE: MVC/XML Framework Comments please
Cheers for Cory! Ejb is THE way to do persistance. By using EJB's properly,
we make use of all of Orion's resource handling capabilities...and these
guy's at Orion are much better at this than I am.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Cory Updyke
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
