You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mike Duffy <md...@yahoo.com> on 2003/10/04 10:44:30 UTC
Re: EJB's vs. Hibernate vs. Torque vs. custom DTO's (EJBs are OK)
I think that Hibernate and iBATIS were probably created in reaction to the inefficiencies and
complexities of EJB 1.1. In terms of efficiency, EJB 2.0 is a significant improvement over EJB
1.1. In terms of complexity, XDoclet offers an elegant approach to coding EJBs
(http://xdoclet.sourceforge.net/).
If you choose a non-standard solution, created by a group of individuals (no matter how capable or
well meaning those individuals are), you run the risk that the non-standard solution will
eventually be eclipsed by a standard solution (see the thread earlier this week on Struts vs.
JSF). The Java Community Process is not necessarily expeditious, but it is deliberate, and it
brings in some of the best and brightest people in the industry (these people are aware of
existing problems).
In the short term, a non-standard solution may be the only choice available. If so, the best
thing to do is to design your code in a way that isolates the non-standard components. If you
really think Hibernate or iBATIS is the way to go, then go through delegates to your data access
layer. This will make future changes less painful.
I think there are standard approaches currently available that offer good solutions based on the
complexity of your application:
If your application is very simple (e.g., you need to display fields from a database on a web page
for an internal application), use the database actions in JSTL. These actions are efficient and
relatively easy. A general rule of thumb might be that any web application that does not require
form input can be done purely in JSTL. Note: This approach is religious heresy to those who
believe MVC is a religion. :)
If your application is moderately complex (e.g., form based input, a few business logic rules, a
limited number of database tables, and the expectation of only a few hundred concurrent users)
then using Struts to handle the MVC and writing your own data access objects is a very workable
solution. The java.sql package is proven and reliable. When you create DAO classes that CRUD
business model classes, a clear method pattern emerges. Also, you have direct control, so you can
easily create specialty methods.
Because Struts will eventually be superseded by Java Serer Faces, I strongly recommend that you
keep your Action classes as light as possible. Do not perform transformations, business logic, or
data access from within your Action class. Get your form bean, send it off to a factory class
that debreifs the form bean into a business model object or objects. Send your business model
object(s)off to worker classes to perform business logic processing. Send your business model
object(s)off to delegates that call your data access objects.
Note: Many of the Struts functions have already been superseded by the functions of the JSTL.
There is no longer a need for Struts bean tags or logic tags. There is a need for the Struts
html-el tags. They allow interaction with JSTL and enable the MVC funtionality. If you limit
your use of Struts tags now, you'll be able to make an easier transition to Java Server Faces and
JSTL.
If you are creating a complex enterprise application, then the services provided by an EJB server
are greatly beneficial (see Mastering Enterprise JavaBeans 2/E, Roman, et.al.). These services go
far beyond persistence. Mostly prior to EJB 2.0, one aspect of these services, Entity Beans, have
been slammed as a poorly designed persistence mechanism. You could drop Entity Beans and mix a
non-standard persistence mechanism into EJBs (Hibernate offers guidelines for doing this; the
creators of JDO also made this case); I think this would be a bad idea.
I think there are times when a non-Standard implementation is the only good approach. That has
certainly been the case for Struts over the past few years; however, (IMHO) that is not the case
for persistence mechanisms today. The short term benefit of mixing in a non-standard persistence
mechanism does not out way the long term benefit of staying with a standard (and not having to
refactor at some future time). There are certainly hundreds (perhaps thousands) of developers
working to improve the implementation of EJBs. This collective effort based on a community
standard will overwhelm the efforts of well meaning individuals working on non-standard
appraoches.
Good luck.
Mike
--- Sasha Borodin <sa...@whoissasha.com> wrote:
> Thank you very much for everyone's responses.
>
> Reading your links and posts, I'm forming the following thoughts:
>
> EJB's
> the bad:
> - more overhead to design and deploy
> - require an app server
> - no inheritance
> the good:
> - standard
> - spec encompasses most (if not all) enterprise features I could
> ever want, and probably never use
>
> Hibernate/iBATIS
> the bad:
> - not a standard spec (IF that's "bad" anyway)
> the good (awesome):
> - I love the "non-intrusive" nature of adding the persistence
> functionality; you don't have to modify your beans
> questions:
> - lazy loading / selective saving?
> - what if an object is spread over several tables in a legacy
> database?
>
> If anyone's got anything to add, please do. I think this is a topic that
> itches the brains of many newbies watching the struts-user list. Thanks
> again.
>
> -Sasha Borodin
>
> On 10/3/03 14:45, "Sgarlata Matt" <sg...@bah.com> wrote:
>
> > I've done a good bit of research on this, and here's the general impression
> > I get from various different sources:
> >
> > * EJBs are good when you need very advanced enterprise features like
> > advanced transaction support and a distributed architecture. However, you
> > need to be careful that your EJBs are designed correctly or they can have
> > serious performance problems.
> > * Hibernate is the most popular object-to-relational tool on the market
> > right now. (I plan to use it in my next project.) The one downside is that
> > it uses the LGPL license, which can be a problem on some projects.
> > * Lots of people like OJB, but I heard once it was tricky to set up. If you
> > can't use Hibernate because of the license, this would probably be your
> > second-best choice. (see Joe's email for additional comments).
> > * Torque is a Jakarta DB project that I am currently using. It makes me
> > nervous because it depends on a few nightly builds and other components in
> > the sandbox.
> > * In the future it looks like JDO will be a good choice. It is a
> > persistence mechanism for Java objects. Strictly speaking, it is not an
> > object-to-relational mapping tool *yet* but I heard it will be when JDO 2.0
> > comes out.
> >
> > Matt
> > ----- Original Message -----
> > From: "Sasha Borodin" <sa...@whoissasha.com>
> > To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> > Sent: Friday, October 03, 2003 3:09 PM
> > Subject: EJB's vs. Hibernate vs. Torque vs. custom DTO's
> >
> >
> >> I hope I'm not comparing apples and oranges; if I am, please excuse the
> >> ignorance, and slap me upside the head...
> >>
> >> The subject line says it all - I'm investigating the appropriate uses of
> > the
> >> above technologies to move data between databases and objects. Thus far
> > in
> >> my development career, I've relied on my own DTO's - homegrown primitive
> >> lazy loading, caching, etc.
> >>
> >> As I'm starting projects for other companies, I'm realizing that no one
> >> wants home-grown solutions where standards and proven products have
> > already
> >> filled the niche.
> >>
> >> Thus, I'd like to get some opinions as to the level of complexity and
> >> appropriate use of EJBs and other object-relational bridging technologies.
> >>
> >> Who uses what, why, and where? :-)
> >>
> >> -Sasha Borodin
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: EJB's vs. Hibernate vs. Torque vs. custom DTO's (EJBs are OK)
Posted by Ted Husted <hu...@apache.org>.
Mike Duffy wrote:
> As someone who started out processing HTML forms with CGI and PERL, I
> am very thankful for the contributions made by the Struts team. I
> often wonder why the JCP didn't take in Struts as a standard and build
> on that standard. Instead, it looks like they kidnapped one of the
> main developers of Struts and started from scratch with Java Server
> Faces. :)
The JSF has been a long time coming. Everything started at about the
same time back then: Struts, Jakarta Taglibs, and the JSF initiative.
The reason we have all three now is that we all began at once, and, at
the time, there was no telling what would survive and what would die on
the vine.
> The key point in determining the dominance of a technology is the quality of the tools developed
> to implement that technology (the "Beast of Redmond" clearly understands this concept). People
> who have resources to invest in the development of tools are going to make that investment based
> on establish standards. That is why I think JSF will eventually supersede Struts.
Some standards are established by bodies like the JCP. Others are
established by the marketplace. Struts support is cropping up in tools
everywhere now, because it's what the marketplace wants. If the
marketplace starts using JSF, then tool vendors will increase their
investment in JSF. But, so long as their is a market for Struts tools,
vendors will rush in to fill the void.
> Right now, the EJB standard is certainly not perfect, but it is OK.
> My guess/hope is that the EJB standard will continue to improve.
> As stated earlier, XDoclet makes EJB incredibly cool to use.
Which is the sort of dynamic that will likely arise between Struts and
JSF. If history is any guide, there will be places where JSF comes up
lacking, and open source projects like Struts will rush into fill the
void. Open source abhors a vacuum :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: EJB's vs. Hibernate vs. Torque vs. custom DTO's (EJBs are OK)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Mike Duffy wrote:
>Correctly stated, some of the Struts taglibs have been superseded by JSTL.
>
>We are starting a major new project and we are trying to guess which technologies have the best
>viability. We have made a decision to use Struts because it is the best current solution and we
>think the controller aspects of Struts will be around for several years. We will use JSTL because
>it is a functional standard that is easy to use and it integrates with the Struts html-el tags.
>We have a "wait and see" attitude toward JSF.
>
>
A perfecty rational attitude at the moment, although I would still
recommend becoming familiar with the new technology. I think you'll
find the adoption uptake (once JavaServer Faces goes final) to be pretty
fast.
>As someone who started out processing HTML forms with CGI and PERL, I am very thankful for the
>contributions made by the Struts team. I often wonder why the JCP didn't take in Struts as a
>standard and build on that standard. Instead, it looks like they kidnapped one of the main
>developers of Struts and started from scratch with Java Server Faces. :)
>
>
Not exactly "kidnapped" -- I'm getting *paid* to develop JavaServer
Faces :-).
More seriously, though, the sweet spot that JavaServer Faces aims at is
somewhat different than where Struts is aimed at. JavaServer Faces is
aimed primarly at providing rich components, and just enough
foundational stuff to build an application framework on top of. Struts
doesn't have a UI component model at all (the HTML tags do not count --
they are simply ways to render simple input fields -- which is why we
have to work so hard at things like tree controls and grids), but shines
in its overall framework characteristics. The right answer will be to
use both technologies when you need both feature sets.
I wouldn't be surprised to see standardization in the web application
framework space at some point ... but it needs to be based on a standard
UI component model first. In the mean time, JavaServer Faces is also
focused on providing sufficient APIs and metadata to make high quality
tooling easier; that is one of the other things that Microsoft learned.
>The key point in determining the dominance of a technology is the quality of the tools developed
>to implement that technology (the "Beast of Redmond" clearly understands this concept). People
>who have resources to invest in the development of tools are going to make that investment based
>on establish standards. That is why I think JSF will eventually supersede Struts.
>
>
Actually, tools support for Struts is pretty broad at the moment, and
inertia is a *very* powerful force ... JavaServer Faces will have some
catching up to do, but it's clear that this is going to happen quickly.
>Mike
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: EJB's vs. Hibernate vs. Torque vs. custom DTO's (EJBs are OK)
Posted by Mike Duffy <md...@yahoo.com>.
Correctly stated, some of the Struts taglibs have been superseded by JSTL.
We are starting a major new project and we are trying to guess which technologies have the best
viability. We have made a decision to use Struts because it is the best current solution and we
think the controller aspects of Struts will be around for several years. We will use JSTL because
it is a functional standard that is easy to use and it integrates with the Struts html-el tags.
We have a "wait and see" attitude toward JSF.
As someone who started out processing HTML forms with CGI and PERL, I am very thankful for the
contributions made by the Struts team. I often wonder why the JCP didn't take in Struts as a
standard and build on that standard. Instead, it looks like they kidnapped one of the main
developers of Struts and started from scratch with Java Server Faces. :)
The key point in determining the dominance of a technology is the quality of the tools developed
to implement that technology (the "Beast of Redmond" clearly understands this concept). People
who have resources to invest in the development of tools are going to make that investment based
on establish standards. That is why I think JSF will eventually supersede Struts.
Regarding a persistence model, Mark Galbreath is right, JDO is a simple answer and JDO is a
standard. JDO may turn out to be the answer, if the EJB specification team does not build upon
the improvements made in EJB 2.0. Right now, the EJB standard is certainly not perfect, but it is
OK. My guess/hope is that the EJB standard will continue to improve. As stated earlier, XDoclet
makes EJB incredibly cool to use.
There is a very good book that goes into great detail on these issues: Bitter EJB, by Tate,
Clark, Lee, Linsky.
http://www.amazon.com/exec/obidos/ASIN/1930110952/qid%3D1065295596/sr%3D11-1/ref%3Dsr%5F11%5F1/102-7314677-9317754
According to the authors, JBoss 4.0 will offer service decoupling, "...hopefully, other
application service vendors [and the EJB specification team] will follow its lead."
One of the interesting things I learned by reading this book is that Entity Beans were an
afterthought to the original EJB spec. In early drafts, the EJB spec was focused exclusively on
distributed components, not persistence. It is not surprising that the original persistence
mechanism was poor. My guess/hope is that within a year there will be a completely decoupled fine
grained persistence service within EJB. Perhaps there will be some sort of "byte code
enhancement" for entity beans. :(
Mike
--- Ted Husted <hu...@apache.org> wrote:
> Mike Duffy wrote:
> > In the short term, a non-standard solution may be the only choice available. If so, the best
> > thing to do is to design your code in a way that isolates the non-standard components. If you
> > really think Hibernate or iBATIS is the way to go, then go through delegates to your data
> access
> > layer. This will make future changes less painful.
>
> Very good advice. Both the Hibernate and iBATIS teams consider using a
> DAO layer to be a best practice (and I suspect OJB does too). iBATIS
> ships a DAO framework as a separate component which works with most
> anything you can name, including Hibernate and EJBs.
>
>
> > Because Struts will eventually be superseded by Java Serer Faces, I strongly recommend that
> you
> > keep your Action classes as light as possible.
>
> Most people have always recommended keeping your Action classes as light
> as possible. Still good advice. But, I don't think that most people
> believe that it is a foregone conclusion that Struts will be superseded
> by JSF. There are people who say such things, but saying it doesn't make
> it so.
>
> JSF does include a navigational element that will be enough for many
> applications. But it does not include anything like the Struts
> Controller. Or Tiles. Or the Validator, Struts-Menu, Struts-Workflow,
> Struts-BSF, and so forth.
>
> I'd say something like "JSF has a lot of catching up to do", but it's
> not an either/or decision. People can, and I'm sure will, use Struts and
> JSF together. The technologies are complementary. Struts is strongest
> where JSF is weakest, and vice versa.
>
> JDBC didn't eliminate the need for packages like Hibernate and iBATIS.
> JSP didn't eliminate the need for XLS or Velocity templates. JSTL didn't
> eliminate the need for custom taglibs. And JSF won't be the final
> solution either. These types of specifications are only the beginning.
>
>
> > Note: Many of the Struts functions have already been superseded by the functions of the JSTL.
>
> > There is no longer a need for Struts bean tags or logic tags. There is a need for the Struts
> > html-el tags. They allow interaction with JSTL and enable the MVC funtionality. If you limit
> > your use of Struts tags now, you'll be able to make an easier transition to Java Server Faces
> and
> > JSTL.
>
> Many of the functions of the Struts JSP taglibs are being superseded
> (thankfully!), but Struts is primarily a Controller. The bundled taglibs
> are one way to access the Controller, but there are many others, such as
> the Velocity Tools and Stxx.
>
> The taglibs generate a lot of traffic on the list (and hopefully JSF
> will draw some that fire someday). But they are not what define Struts.
> Struts is the C in MVC. The taglibs are just a proof of concept. (And a
> great one at that, given they help spawn things like JSTL and JSF.)
>
> With JSF and Commons Chain helping to define what it means to be a View
> and a Model, we will finally have the freedom to focus on our core
> business: what it means to be a Controller.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: EJB's vs. Hibernate vs. Torque vs. custom DTO's (EJBs are OK)
Posted by Ted Husted <hu...@apache.org>.
Mike Duffy wrote:
> In the short term, a non-standard solution may be the only choice available. If so, the best
> thing to do is to design your code in a way that isolates the non-standard components. If you
> really think Hibernate or iBATIS is the way to go, then go through delegates to your data access
> layer. This will make future changes less painful.
Very good advice. Both the Hibernate and iBATIS teams consider using a
DAO layer to be a best practice (and I suspect OJB does too). iBATIS
ships a DAO framework as a separate component which works with most
anything you can name, including Hibernate and EJBs.
> Because Struts will eventually be superseded by Java Serer Faces, I strongly recommend that you
> keep your Action classes as light as possible.
Most people have always recommended keeping your Action classes as light
as possible. Still good advice. But, I don't think that most people
believe that it is a foregone conclusion that Struts will be superseded
by JSF. There are people who say such things, but saying it doesn't make
it so.
JSF does include a navigational element that will be enough for many
applications. But it does not include anything like the Struts
Controller. Or Tiles. Or the Validator, Struts-Menu, Struts-Workflow,
Struts-BSF, and so forth.
I'd say something like "JSF has a lot of catching up to do", but it's
not an either/or decision. People can, and I'm sure will, use Struts and
JSF together. The technologies are complementary. Struts is strongest
where JSF is weakest, and vice versa.
JDBC didn't eliminate the need for packages like Hibernate and iBATIS.
JSP didn't eliminate the need for XLS or Velocity templates. JSTL didn't
eliminate the need for custom taglibs. And JSF won't be the final
solution either. These types of specifications are only the beginning.
> Note: Many of the Struts functions have already been superseded by the functions of the JSTL.
> There is no longer a need for Struts bean tags or logic tags. There is a need for the Struts
> html-el tags. They allow interaction with JSTL and enable the MVC funtionality. If you limit
> your use of Struts tags now, you'll be able to make an easier transition to Java Server Faces and
> JSTL.
Many of the functions of the Struts JSP taglibs are being superseded
(thankfully!), but Struts is primarily a Controller. The bundled taglibs
are one way to access the Controller, but there are many others, such as
the Velocity Tools and Stxx.
The taglibs generate a lot of traffic on the list (and hopefully JSF
will draw some that fire someday). But they are not what define Struts.
Struts is the C in MVC. The taglibs are just a proof of concept. (And a
great one at that, given they help spawn things like JSTL and JSF.)
With JSF and Commons Chain helping to define what it means to be a View
and a Model, we will finally have the freedom to focus on our core
business: what it means to be a Controller.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org