To Map or Not To Map?

[rstearns01]

Having noticed that over 50% of the posts in the Data Access Forum alone deal with Hibernate, I'm wondering if most of the Spring users see an overwhelming advantage of doing O/R mapping. Assuming that's true, let's back up a bit. It reminds me of the beginning of J2EE and everyone wanted to write entity beans.

Is there an O/R feeding frenzy? Having spent the last two years involved with a project that accesses a hierarchical database in a relational fashion, there is a huge impact that comes with short-circuiting what a DMBS brings to the table.

I assume that those doing O/R Mapping would prefer an Object DBMS, yet the lack of such a thing in the mainstream tells me that sufficient justification for one to convince stakeholders of the advantages doesn't exist. The advantages of Spring by removing the requirement of using EJBs is quite apparent. Rod, et. al, have given us a rich set of JDBC helpers and I would like to think they're there for more reasons than "completeness" or backward-compatibility. I did not get the impression from Rod's books that O/R is the holy grail, so what do the Hibernate users see as the great benefit? Have we set the cart before the horse or created a solution looking for a problem or are there 10% of the Spring users using Hibernate and having nothing but problems with it?

Is (and should) O/R mapping be the architectural giant it appears to be?

[rrsIPOV]

I've done a little of both plain JDBC and Object-mapping. I've found that Spring's JDBC utilities/wrappers are very easy to use and reasonable straight forward. For a new project I'd look at the data access - is it mostly table/row based or are a lot of the interactions specified as Objects. If you are dealing mostly with straight JDBC objects than use JDBC; if you're dealing with a lot of Objects then using a standard mapping framework rather than hand coding JDBC into a bunch of classes makes more sense. Also note that with Object mapping you usually can get at least some of both worlds - especially for read-only access you can code reports using JDBC, while using the mapped objects where it makes sense (caching can make write access for both modes slightly problematic).

[jbetancourt]

.... It reminds me of the beginning of J2EE and everyone wanted to write entity beans.

Todays pattern is tomorrows anti-pattern.

But, seriously, I agree with rrsIPOV. Also, in many books there is discussion on the criteria on when to use ORM. Perhaps these criteria will need to get 'better' or more involved in development discussions and thus reduce the inappropiate use of ORM.

I would like to try Hibernate but the application I'm working doesn't need it currently. There is another issue too. The organization or team has to want to learn new stuff. Overcoming inertia is hard. You will hear a lot of "But, ......".

[rstearns01]

Todays pattern is tomorrows anti-pattern.

Quite possibly; I know how we love to try to find places for "new" things (including Spring :wink: ), so I wonder if the volume of questions are indicative of a large number of Spring users with projects where O/R mapping has distinct advantages, many are "test driving" it, or there is a small percentage of users having truly difficult times integrating it.

Overcoming inertia is hard.

Having tried it but not found a use for it yet, maybe I'm full of intertia WRT O/R mapping; I still have discussions with peers about SQL vs. Stored Procs and now IoC vs. Service Locator, yet with Spring the "rather than hand coding JDBC into a bunch of classes" argument mentioned by rrsIPOC really has vanished. The SQL or SP call is now in a configuration file regardless, so to me the question becomes "what is the simplest way to build the object from the result set?" and adding an O/R framework appears as fraught with peril as blind use of EJBs because they're "part of the architecture". Have we come to the point where we can define true best practices for O/R mapping and avoid the same evolution through overuse as EJBs?

Or am I making a mountain out of the proverbial molehill?

[rrsIPOV]

Personally, I think that "Pattern" is being applied to way too many things that aren't patterns. That said, not rushing in to a new idea is good; being too timid is bad. The right balance needs to be struck; and only you/your team/your company can decide what's right for your project.

For me then main advantange of object mapping frameworks are when I want to be able to access an object with more than one or two relationships to other objects that are also persisted these frameworks have standardized the code for this into their libraries. To me it seems that while the current object mapping frameworks are still evolving; they are far enough along to generate some serious interest.

It seems to me that the big difference between object mapping and EJB is that object mapping does not force any other architecture decisions on you.

As for the number of posts; I think the Spring Web MVC and Data Access are the most used parts of the framework (whether in prototypes or actual production I can't say); therefore generating the large number of questions. Also, in my experience data access, whether using object mapping or straight jdbc has a fairly high learning curve anyway.

[dhainlin]

It seems to boil down to scope/context.

I prefer to keep it simple but was once 'saved' by a pseudo-OR framework (torque) on one project that required tight integration within a tweaked Oracle 11i HR system. Without the ability to work from an XML map of the schema and torque's cool round-tripping, I'd have to hand generate over 30 specific DAO instances (and integrate them in less than two weeks). Torque permitted me to focus on biz logic and Struts and was kind enough to get-out-of-the-way when I needed to drop down to do specific JDBC tasks.

On the other hand, prior to clean/simple frameworks such as Spring's jdbc, the only option was to slog it out using JDBC or opt for a more complex OR solution.

It is wonderful to have a spectrum of options. I seem to be gravitating to stock Spring jdbc but know I have iBatis/Hibernate waiting in the wings if scope dictates.