Design Patterns, Marc Fleury and JBoss
I just got back from the Denver JUG meeting and have lots to talk about. I've started this post at 11:03 p.m., for the record. I want to start out with discusssing a topic that Dave and I talked about a few days ago. Basically, in his Ag application, he is using one Business Delegate and one DAO to do all his business logic and data access. Actually, he's got two DAO's, one for Hibernate and one for Castor. Basically, the DAO is determined at startup, set on the Business Delegate and then stuffed into the servlet context. While Ag is a small application, it got me thinking. I believe the recommended pattern for this is to have a Business Delegate for each entity, as well as a DAO. So for a user, you would end up with 4 classes, UserManager/UserManagerImpl and UserDAO/UserDAOHibernate. So everytime I add a new entity, i.e. account, I have to create 4 new classes. What a pain, and a lot of copy and pasting - or at least that's how I'd do it.
Dave's KISS methodology at first struck me as strange, but then I thought, "Damn, that's a lot easier." So now in AppFuse (reference implementation: security-example), I changed to use this idea - with a BusinessManager/BusinessManagerImpl and ApplicationDAO/ApplicationDAOImpl. The idea is that these will contain any and all methods to access data.
I went to the DJUG meeting still struggling this this pattern, feeling like it stunk and I should back it out and go with a factory pattern and a business delegate/dao for each entity. However, during Marc Fleury's presentation, he preached that one of the founding rules of JBoss was KISS. He said that the greatest thing about open source is that no one will ever even look at your code until it's broken. "And how bad does it suck when you have to look through 5 levels of inheritence to figure out the problem?" He mentioned that bad code was his favorite, because chances are - if there's a bug - it'll be staring you in the face, rather than buried inside some design patterns and 10 different classes. I agree, so I'm going with KISS, but I'm also interested in hearing your opinions. I like the current architecture of AppFuse because it sets the business manager on startup, stores it in the servlet context and is available for everyone to use at any time. There's nothing saying that I couldn't set a SessionBean (on the business manager as it's proxy) and call EJBs for my persistence layer.
In fact, after Marc's gospel about JBoss, I want to use EJBs. In fact, not just EJBs, I want to use JBoss - and I can't wait for "JB 4." Why? Well they're adding the ability to add all of EJB's services (i.e. Security, Transactions, Persistence) to any POJO. This means that all you need to do is write a little deployment descriptor for it, and whalla, you're in business. His sermon is something you really need to see to appreciate. I can't do it justice in summarizing it here, but I certainly liked what he had to say, and feel like I'm a better person for it. The JBoss Group's goal is to become the de facto standard for application servers. I like their idea that the app server should be free - and the money (usually spent on app servers) should be directed towards smart developers instead. He also mentioned that JBoss Group (the company) is doing great right now and will be spending some cash on Marketing and PR to squash any rumors that it's not good enough.
Marc mentioned that most of the things he talked about tonight are written in his Blue Paper (PDF, 11 pages), titled "Why I love EJBs". It's part 1 of 3, the Blue of the "Red, White and Blue Technology Trilogy."
Other news that I stumbled upon today:
- JBoss uses JavaGroups, and I've heard you can make work with Tomcat - for clustering and such.
- The release plan for Struts 1.1 Beta 3 has been committed to CVS, code freeze this Saturday.
- Ted Husted defends Struts after I posted it's recent criticizm to the mailing list.
- The xPetstore Application has a new release. xPetStore is a refactored version of Sun PetStore application that shows how to use xDoclet to build WODRA (Write Once, Deploy and Run Anywhere) J2EE application. Tested with JBoss and WebLogic.
Phew, done at 11:44 p.m.