Skip to main content

The Heavyweight Champions are... Springframework and Hibernate?

There are a lot of argumentations exist trying to proof whether a combination of Springframework and Hibernate is still a "lightweight" or already a "heavyweight" champion. Please see following discussions in TSS for some of arguments:
My conclusions after working with Springframework and Hibernate in some of my projects are: yes, Springframework and Hibernate are already our heavyweight champions! Why?
  1. It's getting on my nerves as I have to create SpringBeans by editing those Spring XML files. This is the same with Hibernate hbml files. I know there are some tools available (e. g. Spring and Hibernate plugins) to help me finish these annoying works. But still... at the end this is just the same as working with EJB 2.x with those deployment descriptors. You might say, I can use annotations. The problem is I still have to deploy in JDK 1.4.x. So annotations just won't work. I also know that Springframework 2.0 uses XML schema so the XML files are easier and shorter to create, but again, I hate creating XML files by hand and you?
  2. Special for Springframework XML files and this is often the case: you need one XML file for remote client context, one XML file for local client context and one XML file for test? Gee, how many XML files should I write or copy and paste plus edit?
  3. Hibernate should protect us from the database behind it. Is this true? Until a certain level yes, but if you try to work with Oracle and at the same time with MySQL you will still need to understand the differences between those databases! Do you know that Oracle always saves "" (empty string) as a null value? And this is not the case with MySQL! So welcome back to the relational database!
  4. Do you know how many methods do we have in Hibernate just to persist or create a new object? What are these methods actually for: save, saveOrUpdate, persist, merge? Man, in SQL we just have one command: insert! Do we really need those different kind of methods just for a simple thing? Why can't we just say "save" and everything will be taken care by Hibernate?
  5. I think you already heard a lot about architecture discussion to DTO or not. If not you can check out some interesting discussion in Springframework forum: Transfer Objects. You also can find the same discussion in TSS: Protecting the Domain Model. So, what's the hell why we use POJO if we still have to use DTO? You don't need to use DTO at all - many of us would loudly say, but what if we need to physically separate the tiers? In this case you will meet the most hated exception in Hibernate: Lazy Loading error if you are not carefully design your POJO! So sometimes we need DTO and sometimes not?
  6. If you are by fall putting something wrong in the XML files - both Springframework and Hibernate - (not syntactically because your schema will help you in this case) and you get some errors because of these things. Good luck and have fun trying to find them!
So what are your options?
  1. Accept those points above and be sure to know them best. Why not? You think, the combination of Springframework and Hibernate is still easier to use than EJB 2.x? More flexible than EJB 3.x? Yes, you are right. So, better to have a bad solution than no solution at all. Wow, you are what I call a pragmatic Java programmer.
  2. Use AndroMDAwith the Springframework and Hibernate cartridges. Oh my, I don't want to have something to do with MDA and UML. But what are the advantages of AndroMDA? No need to create those damn XML files - both for Springframework and Hibernate - by hand. You have a standard architecture which will be strongly followed by everyone in your team (if you have one) all the time. Nothing like sometimes with DTO, sometimes without DTO. But still you need to implement those DTOs! Yes, but at least you have the skeletons created for you.
  3. Build your own Dependency Injection and your OR mapper framework which are far better than Springframework plus Hibernate and don't forget at the end you should put them as Open Source products and release them through TSS news :-) So we all can admire your new products: oooh a new very easy framework but also it can support any complex situations (= all you can eat framework - and yes, Springframework is probably getting in this direction too. Of course you don't need to use everything but... we have that, we have this, ... You know what I mean).
It seems that using the option number 2 you will get back those "lightweight" Springframework with Hibernate (no XML files - they will be generated and we always use the same architecture everywhere)? It could be. With the price of using UML? Is this still "lightweight" or we just move our weight somewhere else? At the moment I prefer to use the option number 2 as I feel that I have lot more advantages in comparison of using the option number 1 or 3. But this should not be a general case and should be proven case by case!
Allright, at the end I admit that there are actually no "heavyweight" or "lightweight" frameworks, everything are relative to what exist and to what you know. In any case just take one of your options above and try to solve the problems you need to solve for your customers.
Happy coding and greets,


lofi said…
FYI: Some of interesting comments can be found here at JavaLobby:
despil said…
"With the price of using UML?"

Uhm.. You surely do some design before rush of the hack your code?

Or just simply start to punch in lines, hoping everything will turn out allright?

If the former, then what's wrong with UML?

If the later...
lofi said…
"If the former, then what's wrong with UML?"

For me there is nothing wrong with UML but for many other developers? ;-)

First, you need to have an additional UML tool, which is at the moment quite limited. Second, you need to learn an additional UML language syntax and semantic.

So, I think not all developers want to have these additional burdens.


Popular posts from this blog

Creating Spring Bean dynamically in the Runtime

In my training someone asked me whether it is possible to create an object (a Spring Bean) dynamically so you can choose which implementation you want to have in the runtime. So at the compile time you don't know what object actually should be created yet. The application should decide what object to be created based on a property file.

1. We create an annotation so we can mark the method which should be able to create the object dynamically:

package your.package;
public @interface InjectDynamicObject {
2. Use the new created annotation in your method which should be able to create the object dynamically:
... @Named("customerBo") public class CustomerBoImpl implements CustomerBo { ...     @Override @InjectDynamicObject public Customer getDynamicCustomer() {         return this.dynamicCustomer; } ...
3. Write an aspect with Pointcut and Advise which change the object returned by the method in the step 2:
... @Named @Aspect public class Dyn…

Enterprise Applications Customization with Microservice

Introduction Today in highly paced enterprise environment you, as the leader of enterprise IT division, need to be fast. Simplicity is the key for the speed. What are the key factors to simplify your IT? Three different areas are very important to take care of: Technology, Organisation and Environment(TOE Framework: Here are some detail points for technology and organisation:

1. Technology: in most enterprises there are already one or more ERP and CRM solutions the so called Enterprise Applications. We need to manage them carefully as they support the business processes. In context of the core compentencies most enterprises customize the enterprise applications to fit their needs. We need to manage the customizations in detail as they represent the core competencies and at the same time the differentiation of our enterprise to other competitors. 2. Organisation: working in a small team with different roles and functions is already proved as the best …

Smart Home Sweet Home with Gigaset Elements?

Last week I had a chance to try the Smart Home solution from Gigaset Elements. I read some articles about this product which said how easy to install this product for dummy users. Those articles woke my interest and I began to google products for Smart Home solutions.

In this article (German language) you will find a nice overview about some products for Smart Home, which can be bought in Germany. The Nest product from Google is still not available in Germany. Although it seems that RWE will offer Nest products in Germany in couple of months.

The installation of Gigaset Elements was really easy. The problem I encountered was to add the sirensensor. I had to push hard the button on the siren sensor at the same time with the button on the base, so that they can communicate with each other. After about one hour I managed to install everything properly.

Points to mention
Generally the idea is very nice. Gigaset Elements try to push KISS (Keep it Simple Stupid) principle. Howev…