ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Subject:   "Castor JDO": Simply False Advertising
Date:   2002-12-16 11:49:03
From:   robin@ogilviepartners.com
Response to: "Castor JDO": Simply False Advertising

Hi Sundar


Firstly, thanks for posting under your own name instead of anonymously. It is easy for readers to dismiss the credibility of anonymous replies.


I had a look at your site but found no "category" for object-relational mapping or relational database access. Are your views on this subject covered under another topic?


SQL allows field-level access to data. As such it is a very efficient API, its only big drawback being the lack of syntax-checking available for SQL at java compile time, which itself is quite understandable.


If you like working with SQL and believe it is no hinderence to your application development efforts you should probably continue to use it.


However, if you feel that:
1. Your SQL development is time-consuming, or
2. Your home-grown infrastructure is not sufficiently flexible (e.g. lack of true polymorphism), or
3. Your applications depend on the presence of a relational database when another paradigm may better suit some deployments (e.g. binary file, ODBMS, etc), or
4. Your SQL infrastructure is making your domain model inflexible (field names matching column names, and classes not spanning multiple tables, would be prime examples), or
5. Your SQL infrastructure is "castrating" your object model (value objects with little domain-specific behaviour, but lots of load-save-from-db behaviour), or
6. Your SQL infrastructure requires developers to have a significant level of skill in (a) SQL and (b) your proprietary infrastructure, or
7. Your application is based on an infrastructure known in detail by only one or two developers who might (a) leave or (b) make excessive wage demands (I put that one in for fun!)


...then you should consider JDO.


JDO provides a standard infrastructure that:
1. Is a standard, and
2. Is widely implemented by vendors competing on Quality of Service, and
3. Enables applications to be independent of data store paradigm (relational DB, object DB, etc.), and
4. Still lets you use SQL if you wish (the Query interface lets you specify a query language other than JDOQL), and
5. Provides "Transparent Persistence" - for more info read my book "Java Data Objects" in paperback or PDF, or email me, and
6. Deploys in a client-server, web, or enterprise context, with all the scalability characteristics you'd expect (particularly on the web/enterprise tier), and
7. Is really cool (I put that one in for fun too!).


No-one said you must use JDO...but I suggest that those who employ JDO wisely will have strategic advantage in software development over competitors who do not, which could be cruicial in the current IT marketplace.


And if you do choose the JDO standard, remember to exclude so-called "Castor JDO" from your evalautions! Ok, I think we've rammed that one home now ;-)


Kind regards, Robin.
Robin M. Roos
www.OgilviePartners.com


1 to 1 of 1
1 to 1 of 1