Please excuse the following info-dump :)
To gank Howard Lewis Ship's wording from his Java Posse interview a few weeks ago, Hivemind was designed for building frameworks and Spring was designed for building applications. I'm less familiar with Hivemind than I am with EJBs, unfortunately, but I'm sure it would work just fine in Spring's place, and vice versa, with tradeoffs either way. Spring has a lot of utility functionality built in, though, that I like a lot, particularly with regard to Hibernate. E.g. the HibernateTemplate & TransactionTemplate & JdbcTemplate classes, which ridiculously simplified my data access objects (DAOs) by keeping boilerplate (i.e. code you find yourself typing [copy-pasting] over and over to accomplish the same thing) code out. It's also just easier, in my opinion, to configure the Hibernate SessionFactory via Spring's AnnotationSessionFactoryBean and LocalSessionFactoryBean classes. This is likely where HLS's description comes into play -- I would guess Hivemind handles creating modules and namespaces and wiring more elegantly, but lacks the application-easing utility code that Spring provides. Neither is really a replacement for the other -- you can use either of them exclusively or not at all, though you'll want to be familiar with Hivemind to help you accomplish some Tapestry tasks, as the two technologies are, understandably, intimately linked. With regard to Tapestry, it's very slick and easy to have Tapestry start the Spring engine, which in turn starts the Hibernate engine. It's similarly effortless to access Spring-managed beans from Tapestry pages, etc. From what I saw about using Hibernate with Tapestry directly, it just seemed messier, but I admit I've never tried it. I believe I'm ganking more of HLS's phrasing ... but it was said (also on that podcast) that EJBs were built to handle all the concerns that a very large enterprise would have to deal with, e.g. transactions distributed over servers across the country, etc. This is overkill for most Java-based web applications, as your small-business e-Commerce site isn't going to benefit from all that, and meanwhile your application's development will slow to a painful trudge as you have to deal with all the complexity. It is my understanding (and experience) that for medium-sized projects, Spring and Hibernate can give you most of the help the EJB framework would, but with much less impact on your code and a generally more-pleasant experience. For huge enterprise-scale projects, EJB might be a consideration, but if you can wait until EJB 3.0 is released, that would be nice, as allegedly EJB 3.0 is much simpler, taking cues from all the lightweight frameworks it found itself losing to. (btw, the creator of Hibernate [Gavin King] is heavily involved in EJB 3.0 persistence -- so the difference is going to be much less substantial very soon; I'd use Hibernate now and then take a gander at EJB 3.0 when it comes out and decide then ... it should fortunately be pretty easy to switch over, especially considering Hibernate supports EJB 3.0 Annotations on your POJOs) Personally, I am heavily biased toward the Spring/Hibernate/Tapestry stack -- my DAOs are extremely readable and easy to manage and test ... what used to take 30-40 lines of JDBC code took 12 using Hibernate, and then 1-2 lines when I further worked in Spring's HibernateTemplate class. And Tapestry's component framework means I can have my developers creating components independently, and my web designer making everything pretty, without everyone stepping on each other's toes. It really makes development fun again (Struts was really nice at first but then it made me cry), which is probably why I'm approaching my 24th voluntary straight hour here at the office and it's Saturday morning now. Regarding performance, I have zero understanding of EJB's performance. Speed-wise, I haven't run into issues yet with Spring/Hibernate/Tapestry; though granted, my web applications have very small audiences, but all three technologies are designed to scale well. My only issue has been having to completely stop hot-deploying to Tomcat, as all three technologies exacerbate a memory-leak issue with Java's classloader that takes Tomcat down rather unelegantly after 6-7 deploys of a modest application. And even then, as the applications are used, more and more proxy-classes are loaded and after a few days Tomcat would run out of memory even after a clean restart. But this was largely my issue -- I was squeezing two S/H/T applications onto a server with about 10 other (Struts) applications on it, with only a Gig to share among them all. You just have to be honest about load-testing and monitoring your application to see how much memory it uses, is all, and I'm sure that is true for an EJB application, though I can't say with any authority whether it experiences the same kind of issues. But the bottom-line was that the hours and hours of development-time saved (particularly with regard to maintenance -- a S/H/T application is marvelous when it comes to having to change it later, compared to a Struts application [at least, the Struts I was using a year ago]) more than compensated for the financial cost of installing more RAM on the production server mentioned above. And that's everything your e-mail inspired me to say so far : ) Jim -----Original Message----- From: Andreas Bulling [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Bulling Sent: Saturday, February 18, 2006 5:32 AM To: Tapestry users Subject: Re: [OT] Re: Best practice - Integration Hibernate/Tapestry Hi Jim, first, thanks _a lot_ for your quick and helpful answer which I appreciate a lot! It made me feel a little bit happier again after this painful day as there's a small light at the end of the tunnel, now ;) Especially as you mentioned some of the terms I've read over the day but could not class correctly so far... So, that means basically I have to decide whether I need the EJB functionality or if a POJO-based approach is enough for my application *thinking* Perhaps someone else can answer the following questions then: Why should I use EJB's at all now that Hibernate does such a great job? Is there a situation where using EJBs _and_ Hibernate makes sense and if yes, how can they be brought together? Are there performance issues using a POJO-based approach and perhaps EJBs should by all means be used in bigger applications or shouldn't that be a problem? What are your experiences? What about the idea to use one single session bean providing all methods needed to handle the POJOs and hibernate? Jim, you mentioned Spring and I'm wondering what Spring is good for? How does it "bridge" between Tapestry and Hibernate, how did it make your life easier? Which role plays Hivemind in this whole constellation? I'm not sure but perhaps Hivemind is just a replacement for Spring? Thanks again! Andreas On 17. Feb 2006 - 19:19:50, Jim Steinberger wrote: | Hi Andreas, | | Hibernate is an alternative to EJB CMP, though I'm sure you could use | the two solutions together if you had/wanted to. Both are a way of | bridging your Java classes and your database tables by mapping them -- | the goal is to not have to write SQL manually ... or rather, the goal is | to not to even have to think about the database as anything besides a | place where your Java objects go to ... hibernate :) | | | EJB2 CMP was very intrusive, from what I've heard, requiring you to | extend certain classes and/or implement various interfaces, ensuring | that your basic domain-model classes would only be relevant inside an | EJB container. Hibernate, on the other hand, lets you simplify your | domain-model back to plain-old-Java-objects (POJOS). Your objects are, | therefore, relevant anywhere, and you get the Object-Database bridge | without having to deal with the complexity of an EJB container. | | | I've never used EJB, let alone with Tapestry, so I can't really say much | about that. But I can say that if you were interested in creating an | application without EJB CM, I personally use Spring to bridge Hibernate | and Tapestry together and I'm enormously happy with how well my code is | organized/modularized as a result. | | Integrating Tapestry and Spring: | http://wiki.apache.org/jakarta-tapestry/Tapestry4Spring | | Integrating Spring and Hibernate: | http://static.springframework.org/spring/docs/1.2.x/reference/orm.html#o | rm-hibernate | | Feel free to e-mail me directly if you'd like me to go further into | Tapestry-Spring-Hibernate; sorry I can't help with EJB questions. | | Jim --------------------------------------------------------------------- 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]
