Last updated : 05/03/2003; 21:28:34 Joe's Jelly Joe Walnes rambling on and on about Software Development, Java and Extreme Programming.
NAVIGATION >>	/WIKI /WEBLOG /THOUGHTWORKS /OPENSYMPHONY /EMAIL
:: ELSEWHERE xp developer wiki c2 xp wiki the server side javaworld sd magazine jakarta :: BLOGS Ara Abrahamian Mathias Boegart Mike Cannon-Brookes Paul Hammant Aslak Hellesøy Darren Hobbs Patrick Lightbody Charles Miller Brett Morgan Rickard Öberg Joseph Ottinger Mike Roberts Chris Stevenson James Strachan :: INVOLVEMENTS SiteMesh QDox MockDoclet OSCore OSUser PropertySet RichTags Marathon SiteMesh C++ Alt-RMI Jelly MockTags more... :: BACKLOGS February 2003 Sun Mon Tue Wed Thu Fri Sat             1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28   Jan   Mar :. 03 February 2003   11:08:21 PM   JDO, or O/R So somebody pointed me to JDO. It seems to be a good replacement for our DAO layer. Map your objects to a DB without too much complexity. But I'm quite hesitant: will it solve our performance problems? Will it be as easy to convert our application as it looks? Even worse: if we decide to go for JDO, do we need Sun's JDO spec, or is Castor's better? Sun's spec doesn't seem to have a free implementation, which makes it riskier to invest in that option. I've heard a lot of good of Castor, but it was about it's XML serialization. Are they as good in O/R mapping? I'm looking into it, but real-life experience would be very welcome. I'm kind of searching around in the dark, with a flashlight that only reveals positive points.[Feelings and Thoughts] Despite the contravercy, JDO is actually a really awesome spec. If you can live with having to incorporate a byte code enhancer into your build process it offers a very clean and elegant solution with very minimal overhead on your code. If you are going for JDO it's best to hide all the javax.jdo stuff behind a simple facade as it's a bit convulated to get started with. The downside (and upside) to JDO is it's only good as the vendor implementation you choose to use. Unfortunately, most are no good - including the reference implementation. I can vouch for KODO though as it's a truely AWESOME implementation (the finest O/R tool I've ever come across). It's a commercial implementation that's licensed quite reasonably on a per developer basis with a royalty free runtime. My favourite feature of KODO is the sensible defaults. In almost most cases all I need do to a class to make it persistent (and ensure the database schema is setup correctly) is add the @persist JavaDoc tag. KODO is very robust and scales wells (even in clusters). If you want an opensource tool, Hibernate is also a fine choice. Featureswise it matches KODO and is very flexible to work in a way that suits you best. The main drawback is that it is a bit more work to persist an object. Of course, life is simpler still if you avoid the relational database altogether :).
Web-design by John Doe from open source web design.