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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
