The No.1 i-Technology Magazine in the World !
   
 

      ES no BS
This is a personal blog of Yakov Fain       My son's animations and music         No BS IT podcast      Америчка




Archives

««Sep 2010»»
SMTWTFS
    1
2
34
567891011
12131415161718
19202122232425
2627282930

RSS Feed








Subscribe to these blogs

Do Spring combined with Hibernate weigh less than EJB?

posted Tuesday, 19 September 2006

Lofi Dewanto in his blog asks if Spring framework used with Hibernate is still a lightweight or a heavyweight champion of Java frameworks? 

I believe that not only this combo, but even each of them separately is pretty heavy as ANY framework. Only reusable loosely coupled components are lightweights.

Spring framework is advertised as a set of components that can be used separately, but you can also wire them together by adding two pounds of XML. The minute you do this, you fall into an XML  trap.  So if you use any single component of the Spring framework it's lightweight. But as soon as it takes two to tango, and you are pulling a tiny roll of thin wire out of your pocket, it becomes heavyweight. Because wires (a.k.a. XML) tend to twist and create a mess.

Speaking of Hibernate, I'm not even sure WHY so many people are using it in the first place? I can understand if  an enterprise architect is laying out a new design of a stack of business applications and wants to enforce  to a firm-wide standard for  data persistence.  But if you are developing a typical CRUD application, especially when it comes to using already existing and not perfectly designed database, why even  bother with Hibernate? Do you really hate or afraid of SQL?

Anyway, take an application built on the Spring framework components interconnected with thin wires, put on top of it Hibernate with the wires of different diameter, and maintainability of your application decreases while hard to find bugs are making themselves at home in  your application. 

During the last three to four years  many people like  bashing EJBs as an unnecessary complicated framework with lots of convoluted XML descriptors.   Now EJB 3.0 with its annotations is trying to appeal to enterprise developers again. This won't be easy, because bad memories last for years. But do not kid youself when you substitute  EJB for Spring/Hibernate combo. Your life won't be easier at all.

I do believe in standalone POJOs which know nothing about environment they are in (an IoC concept works fine), and know how to perform a specific function, i.e. send a message, manage transactions, create a pretty report based on provided SQL, model some financial process, find an optimal route, e.t.c. Just pass the required parameters to this black box, get the result back and do whatever you want with it. Stop  wiring, just write the freaking code specific to your business application and forget about it when the new project start. Do not forget though about independent reusable components. 

 Spring is probably one of the best Java frameworks available today. It has only one drawback: it's a framework.

tags:        

links: digg this    del.icio.us    technorati    




1. Hung Tang left...
Tuesday, 19 September 2006 6:08 pm

Because wires (a.k.a. XML) tend to twist and create a mess. Is it really? Every application has to deal with wiring dependencies between components for them to work together, and the use of XML in Spring is where much of this functionality is implemented. Besides, wiring components in Spring can take place over several XML files so modularity with respect to seperation of concerns can be achieved through the use of XML. For me, managing these XML files in Intellij is just fine; locating them is two key-strokes away CTRL-SHIFT-N and CTRL-B. Its comfortable to know that, as a developer, I have one place to look for the wiring instead of crawling through actual code (which may not look pretty) to find it. Lets just say I could untangle the mess much quicker through use of XML.

But if you are developing a typical CRUD application, especially when it comes to using already existing and not perfectly designed database, why even bother with Hibernate? Do you really hate or afraid of SQL? It really depends on the requirements. I have a requirement to create dynamic search queries for my data and Hibernate QBE and Criteria API works well. I also run a high-volume, database-driven application that needs to be able to support many concurrent users at the time, and hence caching would be nice. Hibernate has built-in caching for data access (may even support cluster in some implementations) that I was able to leverage. I could write these services myself, but that's silly when I leverage these from a popular, ORM like Hibernate. I don't believe there's anything wrong with combining both Hibernate + SQL via Spring's JdbcTemplates, or roll your own.


2. Yakov Fain left...
Tuesday, 19 September 2006 9:57 pm

Since you run high-volume database-driven application, intimae knowledge of SQL helps tremendously. Add to it a standalone reusable cache component, and your application will rock. Is it worth using Hibernate jsut because it has a cacheing component?


3. sduskis left...
Wednesday, 20 September 2006 9:36 am

@heavyweight: I agree that Spring & Hibernate are heavyweight, but based on your definition of lightweight, the applications that I write in the aforementioned frameworks are lightweight :)

@xml: The most common approach for configuration Java 1.4 is XML. If an environment has Java 5+, Spring and Hibernate both can both use annotation driven configuration. Comparing EJB3 and Spring/Hibernate in JDK 1.4 is unfair... Pretty soon Spring/Hibernate shops will see the "light"

@sql: even if one is using Hibernate, it behooves him/her to have intimate knowledge of SQL. Hibernate brings plenty of tools to the table to ease the complexity of developing complex applications. However, I do agree with you about developing simple CRUD apps... but a developer should have access to a set of utilities that make JDBC calls a bit less tedious (for example utilities that can do all of the resource opening and closing).

We're not afraid of SQL. We just need a few more tools for a higher level of abstraction than JDBC provides.

@maintainability & bugs: My experience with Spring/Hibernate was that bugs were found earlier in the cycle and were easy to fix. Adding new functionality has also been pretty easy. I'm not sure why you assert the opposite, and I'd be glad to hear your rational given your status as a Java champion.

@Componentization: How do you suggest managing components? If the component doesn't know about the environment, the environment (whether framework or hand-coded) has to know about the component and how to put them together. I thought that the definiton of "wiring" is the act of putting together components... so I guess you advocate that you write componets and "wire" them by hand... :)

Overall, I think that there needs to be a few distinctions: Java 1.4 vs 5.0; and small projects vs. large. A small project in a 5.0 environment is very different from a large Java 1.4 project. My guess is that the Spring/Hibernate noice is mostly coming from large Java 1.4 projects :).


4. Yakov Fain left...
Wednesday, 20 September 2006 9:54 pm

@sql. Anyu decent enterprise programmer must know SQL. Period. Yes, tediuos JDBC programming has to be automated, and we do this not for Java though, but for Adobe Flex. We use Java, metadata and XSL to automatically generate all JDBC code required to populate a datagrid (if interested read this article: http://www.adobe.com/devnet/flex/articles/daoflex.html ). I'm not sure if there is a need, but we can easily modify this software to generate Swing JTable from an SQL statemnent.

@maintainability & bugs. The less moving parts, the better, less chances that someone make a mistake and introduce a bug. Also, dumb down programmers spend most of their time configuring XML instead of doing programming.

@componentisation: youi need a cache object, get if from someone, rollup your sleeves create an instance of this object passing to its constructor all required params. Stop wiring, do programming


5. HUNG TANG left...
Thursday, 21 September 2006 10:12 am

@sql--SQL is not rocket science here, lets agree on that. Any decent programmer can pick up the basics in an hour or less. For me it was the case. I do agree with you that every developer should have a solid understanding of SQL but that doesn't mean we should /always/ use JDBC. JDBC is error-prone, and it shouldn't be the choice of framework for performance. Optimizaitons can offen be applied at the database level rather than at the application level to reap a lot of gains. So how does JDBC help me to become more productive?

@xsl--How is your approach to using metadata (assuming stored as XML) and XSL is any easier to maintain? I doubt it is any simpler. Assuming you are not the only developer on your team, other developers would still need to learn the basics of XML and XSL(T) to maintain what you have created in the event that you leave from the project some day. From my past experience, XSL(T) is complicated to use properly and I wouldn't use it unless all my data was strictly based on XML. If your project is not solely based on Java, and only Java, then it'll be complex to an extent measured by the function of the underlying technologies and tools employed for the project. The point here being is that you can't escape from complexity. Only discipline and practices that you preach and instill onto others can help manage that.

@maintainability. murphy's law--anything that can possibly go wrong, does. Your advice to continue programming without careful understanding of your design will only lead to disaster.


6. Yakov Fain left...
Thursday, 21 September 2006 10:38 am

@sql - At one of my recent presentations to Java developers, I've asked the question, "Who knows how to delete duplicates from a database table?". NO ONE KNEW. Do you know? When I asked the same qst on one of the online forums, some Java developer proudly announced that with Hibernate you do not create duplicates in the first place". Thank you very much! How about some real world experience? What if the database table with dirty data already exists and dirty feeds keep coming in nightly? Do not kid yourself. Learn SQL.

@xsl - we've created a component that uses xsl templates, but you do not have to know how they work, unless you want to do something similar. If interested, here's an article on the subj: http://www.adobe.com/devnet/flex/articles/daoflex.html

@maintainability - when applications are put together by configurators vs. programmers, this can also lead to a disaster.


7. Hung Tang left...
Thursday, 21 September 2006 11:26 am

@sql--I just witnessed a "Alex Trebek" phenomenon. Just because you asked a question in which you know the answer for (most of the time related to your own personal experiences), doesn't mean everyone should expect to know the answer. I could easily come up with a related SQL/database question in which you could not provide a 'correct' answer, does that mean you are incompetent? No. Reminds me the time when an interviewer asks me would Test.java -> "class Test { public static void main() {} }" would compile (notice the missing String[] args). I didn't really care. If you know, then great, but I hope you see the point I'm trying to demonstrate.

Please define what 'duplicates' is/are. Is it one in which two or more rows whose key column(s) contain identical values? If that's the case, why weren't constraints set to prohibit this from occuring? Doesn't make sense to me that duplicate rows should occur in practice. Suppose even if they do occur, this problem isn't too common to warrant becoming an SQL expert. I could easily find the answer with a google search.


8. Kazi Rameez left...
Thursday, 5 October 2006 10:19 pm

First, I would start with thanks to Yakov Fain on his excellent writing. Between Hung Tang and Fain discussion I was enjoying the topic both that both of you brought here. I read a lot articles about Mr. Fain and his dimension of knowledge is more than normal dimension (which is 3-dimension). On the above discussion, I would go both of you partially. In Mr. Fain articles and books, the things you noticed he evaluate new things about JAVA, excellent. But, the thing that I missed is things are changed now in this Google and Open Source movement. Companies are participating in the Open Source and everyone how is planning for Open Source Business Model knew that Open Source is a medium of collaboration. I'm not trying to teach you on Open Source who knew better than you about JAVA and Open Source. But if this is true then Mr. Tang is correct on his words we should think more on business and think less (not saying avoid it) on core depth architecture.

The article nature and his context, I am the one who stands on it. Today, JAVA have almost several frameworks on each TIER (how much possible) and each frameworks means learning. Without knowing a proposed framework you no one couldn't proceed or even think to implement it on his small business or enterprise application.

I had a good discussion on theserverside.com about Web Frameworks. The members on that discussion knew about every framework but expert in one and utilizing that single peace of knowledge well over their past experiences. So, it would be better to choice one and stick with it until you wont' have reasons.

I loved the specification of EJB 3 and will stay with it.

Knowledge is good thing that everyone likes to get it for free :) But be cho-z


9. Norman left...
Tuesday, 17 October 2006 2:38 pm

By bringing in a new framework, you create a need for new experts which translates to better consulting rates. I think that the proponents of XYZ framework have a monetary reason to push their respective frameworks irrespective of wether the framework is the best suited for the job. First it was struts, then hibernate/spring, and when there are too many programmers versed in hibernate/spring someone will start the ball rolling on the next best thing.


10. Yakov Fain left...
Tuesday, 17 October 2006 2:48 pm

Well, I do not think someone starts develoment of a new framework just to increase his rate. There is a long way before a framework is created and someone start using it (and paying high rates). In terms of making noise, I am very impressed by the Ruby on Rails guys. They make A LOT of noise and they are making money now...While the RoR may be over-rated, a small number of companies that decided to use it can provide a decent cash flow to a small number of people who are experts in it. But again, I do not think that David H. has created RoR just to build a new market for himself. First it happened, and then he's winning the mindshare of Java developers in a smart way.