Object-Relation Mapping without the Container

Justin Powell writes "If you follow the latest developer buzz then you've likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming). Like many developers, however, you may not see where these technologies fit into your development efforts. Learn where they can fit with a hands-on introduction to using Hibernate and Spring to build a transactional persistence tier for your enterprise applications."

Comments

Yeehoo, more tools.......

[MrIrwin]

After all, Java development environments are well known for thier conciseness and simple nature. Let's throw another couple of tools into the works....

Re:Yeehoo, more tools.......

[bay43270]

After all, Java development environments are well known for thier conciseness and simple nature. Let's throw another couple of tools into the works....

Your comment seems to sum up J2EE fairly well. This is why Spring was created. A container should provide a framework for containing things. period. If you want persistence, add a persistence framework. If you want transactions, add a transaction framework. If you think you need all the extra complexity, feel free to add it.

J2EE, however is complex by default. Spring tries to get away from that. Whether Spring itself can replace J2EE has yet to be shown, but it's philosophy will (at least in those companies flexible enough to change).

J2EE was a good first step, I suppose. They combined all the complex middleware software of the early to mid 90's into one giant all-inclusive spec. Anyone with a couple million man hours could implement the spec and join the market. I guess it made sense at the time.

Now we have a handful of application servers each costing tens of thousands of dollars (not including two very nice open source implementations). Most companies opt to spend $20k on WSAD just for transaction support, or just so they can use the app server's security. They never stop and ask if they need all the power their buying. Spring (and the light weight containers that are sure to follow) will give people an alternative.

A lament to Java.

[Roman_(ajvvs)]

I used to promote Java as "the tool" for development, but after 2 1/2 years of not being able to justify the use of my formerly favourite language in a single commercial project, I can only sigh. The biggest stumbling blocks have been the getting effective tools and the limiting the overhead and complexity of any potential implementation. The current Java SDK's are not intuitive. I loop hopefully to 1.5 and Eclipse for evolution in the right direction, but Java right now feels like a colossal waste of my paid time. It's partly because of things like this (line from the article):

Unlike EJB CMP CMR and like JDO, Hibernate can work inside of or outside of a J2EE container, which is a boon for those of us doing TDD and agile development.

Acronym hell. Java used to be pretty easy to understand. There was Swing, there was AWT, there was the language and the development environment was concise. Not all of it was good, but I knew where I stood. Right now I know that 4 of those 6 acronyms aren't relevant to my work as a programmer. And none of them relate to Java as a language. People talk about ATL, STL, MFC and whatnot, but C++ the language has endured as a language independent of its modules. Love it or hate it, it's a language that deserves respect for this endurance. Right now I can't say that for Java. Whatever happened to plain Java?

Maybe I'm just not getting it, but me "getting it" is what's the deciding factor in my choice of tools, since I have to get it to do my work. I get .NET; there's the language (C#,VB,C++,WinForms, all .NET) and there's the tool (Visual Studio, maybe Mono). I know for a fact I can write code using VS that can compile on linux with the minimum of modification. I also know which modules lock me to windows (VB.NET, Winforms) and which ones don't (maybe C# if Mono succeeds, Strict C++ saves the day for portability). I learnt this from documentation, research and testing by my own hand. I've researched Java, kept informed of it, but all I see now is a concoction of marketing hype and a bad case of constant scope creep. Another quote:

The starting point is an enterprise application for which you are implementing a transactional persistence layer.

Overkill! I'm sorry, my customers aren't going to spend the money buying our software when they need to install an entirely new infrastructure to support it. The margins aren't that high in my industry. Besides, why do I need yet another framework? What was wrong with the old one? If the old one was so bad it had to be replaced, why promote it in the first place? I don't care about an implementation of the newest development methodology. I care about development cost, infrastructure, what customers will put up with, and what I can support without costing me a fortune in time, effort and understanding.

This article showed me nothing that gives me any clue to how useful this is really going to be "in the field". I think I'll just go hibernate until Java springs into action...