This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Object Relational Mapping and the fly likes Why Kodo JDO? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Why Kodo JDO?" Watch "Why Kodo JDO?" New topic
Author

Why Kodo JDO?

Charles Hasegawa
Ranch Hand

Joined: May 22, 2003
Posts: 117
We considered JDO for a project recently (getting so far as deciding that Kodo would probably be our solution choice), but came to the conclusion that the only thing that a JDO layer offered was "the programmers don't have to know SQL".

So, what does one gain by using JDO - specifically Kodo? There are a number of tuning tricks that can be done in SQL if your queries are slow, are there similar programming tricks that can be done with kodo if performance isn't what you'd hoped?

Did we miss something else? If your programming team has decent experience and understanding of SQL and query tuning, is there any reason to use a JDO?
Robin Roos
author
Greenhorn

Joined: Nov 01, 2004
Posts: 15
One aspect is all about developer productivity.

Consider an application with X thousand lines of code under management, which delivers a set of features for the business to use. What I'm most interested in here are the lines of code which are actually in the version control system, which would include descriptor files which drive code generation tools but excludes the code generated by those tools. The amount of code under management has a direct relationship to the resource cost of maintinaing the application and enhancing the features it delivers.

JDO lets developers think and work at a higher level of abstraction if they want to. Object mappings are managed as configuration data outside the application code. Algorithms for persistence by reachability, dirty tracking, etc. mean that very little code has to be written to actually deal with persistence concerns. The concept of "transparent persistence" means persistnece is transparent to the domain object model, so persistent objects behave comparably to their transient counterparts and can be tested outside the persistence environment.

The lack of constraints facilitates object models which go beyond the JavaBean conventions where apprioriate: no problem with final classes, private fields with no accessors, etc.

All of this adds up to a smaller codebase delivering the same features with a level of abstraction which is more related to business features than to infrastructure concerns. From the business stakeholders' perspective, this means increased developer productivity.

Of course you can still tune Kodo in many ways, and JDO 2.0 adds fetch groups and native SQL queries to the developers' arsenal. So you can fall back to SQL if you have to, whilst retaining the benefits of a transparent persistence solution.

JDO is remarkably efficient, in part due to its non-reflective architecture, in part due to its automatic dirty-checking, and in part due to the competition between vendors (including SolarMetric) to make their products stand out in the market place.

Cheers, Robin.


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0321123808/ref=jranch-20" target="_blank" rel="nofollow">Java Data Objects</a>
Thomas Whitmore
Ranch Hand

Joined: Aug 05, 2004
Posts: 33
We considered JDO for a project recently (getting so far as deciding that Kodo would probably be our solution choice), but came to the conclusion that the only thing that a JDO layer offered was "the programmers don't have to know SQL".

Productivity is pretty important, in developing business systems or database applications. Writing all that JDBC code by hand will probably take 30% of the devlopment time & effort in your project, and you've probably noticed that it's pretty much boilerplate.

If you get an engine to do the DB access & mapping for you, you wipe that task off your plate. You also get the flexibility to change or re-map your schema, and the engine will allow use of different access paths & queries off the same set of mappings. Which is pretty much win-win all round.

Feature wise you can look for things like configurable fetch, reference joining, integration features, query result expressions to retrieve large data structures, caching for commonly-used data etc.


For one Order-OrderLines-Product example, we can see 1500+ rows per second retrieved. This case used the query features to specify retrieval of the subordinate data, and should be widely applicable since Order-Lines-Product is such a common business example. Only basic hardware and a Java database were needed to achieve this.

Hope this helps.


Cheers,
Thomas Whitmore
www.powermapjdo.com
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why Kodo JDO?