Aaron, You've opened up a big can of worms! There is much debate on this topic.
Regarding entity beans and transactions: The recommended practice is to use the 'Session Facade' pattern to wrap access to your entity beans inside a stateless EJB session bean. The reason is remote calls to entity EJB's are too slow. Instead, only use local interfaces for you entity beans. Your Struts actions would never talk to entity beans directly; instead they would call 'service' methods on session beans. This also means you need lots of little data transfer beans to transfer the data in and out of the session facade. (Or you can sacrifice explicitness and type safety and use dyna-beans.) The session facade also provides a good place for transaction boundaries. An action will usually call one method on the session bean, and that method is a transaction. The user hits a button, and either all his changes or saved, or they all get rolled back. That kind of 'atomic request' is a nice simple transaction model that works for most situations. However, there is a lot of extra effort involved in creating the session facades and data transfer objects, and keeping them in sync. Example: the xPetStore application, which shows how to use xDoclet, was implemented twice, once using EJB, and once using just Servlets and Hibernate (an open source O/R mapping tool). Excluding the code that xDoclet generated for you, the EJB version still had more than twice as many lines of source code in the business tier compared to the Hibernate version. So even with a tool like Xdoclet, there is still significant extra cost to doing EJB. Also, as Robert alluded to, EJB entity beans don't really support object-oriented development. A good OO domain model is typically fine grained, with inheritance, relationships to other objects, etc. The fact that entity beans don't allow re-entrancy (object 'a' calls a method on object 'b', which calls a method on 'a'), inhibits your entity model. Of course, if your business model is simple, that might be OK. IMHO, the only compelling reason to use EJB is if you need to provide access to remote Java clients to your business tier. (Web services are another option that also supports non-Java clients. But they do add overhead.) Even there, I would just use session beans, not entity beans. In our app, we're using Struts with Hibernate and doing everything in the web container. We have a servlet filter that start, stops and rolls back the transaction; the 'atomic request' approach. Getting EJB out of the mix really simplified things for us. We do have a few cases where a remote Java client needs to talk to our business tier, so we will probably use EJB remote session facades for that. But we'll only do the extra work when and where we need it. Hibernate allows you to declaratively cache read-only objects. (Or read-write too, if you're not using a cluster.) Ted Husted has an example app on his page using Struts and Hibernate. OJB is another popular option. Long term, JDO may or may not catch on . All of these tools over true transparent, object-oriented persistence, in stark contrast to EJB entity beans. Steve -----Original Message----- From: Robert McIntosh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 10:39 AM To: Struts Users Mailing List Subject: Re: [OT]: Struts, Web Development, J2EE, and what is too much? Tony made some good points, and my take is that from your requirements, you may not need EJBs. However, if you layered your app sufficiently, then if you end up needing them later on, it shouldn't be too much of a problem. Of course I am assuming you are referring to Entity beans in this case... As for when to use EJBs, what I have always recommended to our clients is that EJBs are good for large scale applications that run on clustered machines and require transactions at the entity bean level. The transactions are good if you have multiple apps and clients that are modifying the same data. If your app is largely read only, it is the only one interacting with the data and you aren't worried about concurrent modifcation, then you probably don't need entity beans. Yes, most app servers can cache and mark entity beans as read-only or mostly read-only for performance, but there are other ways of doing the same thing. Another thing to consider is how your object model is designed. If you have lots of inheritance, entity beans aren't going to fit you well. Same can be said if you have complex query requirements (joins, relationships that the object model doesn't support, etc.). Then again, in some cases as Nash pointed out, EJBs can be simplier from the perspective that any good app server can build the database for you and with tools like XDoclet, you don't have to write deployment descriptors and you don't have to maintain (i.e. code) the interfaces for home, remote and local. - Robert Aaron O'Hara wrote: >I know this question has probably been asked before, and that biased >publications have had their opinions on it, but I wanted to get some >feedback regarding some "real user experience" regarding the use of EJB >in a web application used along with Struts. > >I am creating a web application and I have decided to use struts. The >application needs to be high performance, uses a single database (so it >doesn't have heterogeneous transactional db requirements). I have >designed the application in layers, and it will only have a web >interface. It's starting small, but will grow to have many functions. >Even though I'm confident that I need not invest in EJB's, I don't want >to develop the application to find out I should have used them (hence >why I'm creating this post). > >In what scenarios have people found the use of EJB beneficial? When >have they been overkill? Does struts integrate smoothly with EJBs? > >My fear is that I'll make the application overly complex by implementing >EJBs, but I'd like to hear from people with experience building large >web-only projects with struts. > >Thanks, > >Aaron > > > > >--------------------------------------------------------------------- >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]
