| |
3:28:53 PM |
 |
ROI on O/R Bridges.
The overall question is: Who needs OR bridges, when you have kool stuff like Relational Databases and SQL? Is this nothing more then a dirty hack and does it put useless complexity to your projects? [Gerhard Froehlich]
O/R bridges and all the gunk has two costs. One, the learning time for you. Two, the increased restrictions on your coding style. But, in theory, the aforementioned investments should be payed back on large projects. I think Mike, with JIRA, would be well placed to answer the question on whether a persistence framework pays back on a largish project. [Brett Morgan's Insanity Weblog Zilla]
From my experience, if you're building a system and are constrained to a relational database a good O/R persistence layer is essential. The way to think of it is to imagine you have no database at all. Go away database.
Now, you're building a system out of objects that lives in memory - magically the memory always lives. Your objects can represent state, relationships and behavior all in one. To persist it, all you have to do is add it to a hashtable. The code is so clean. It's agile. You can do smart things with it (try implementing the strategy pattern in SQL). And performance is great because you're not constantly worrying about network latency as you hit a db.
Developing like this is a so simple and fast.
A good O/R tool allows you to build applications like this and have objects transparently mapped to the db. Here's my personal criteria for a choosing an O/R tool:
- Minimal interferance with domain code. Classes should be created as if there was no database involved and the tool should be able to do whatever magic it needs without adding work for the developer. Design constraints and support config files / classes should be kept to a minimum.
- Classes define all. Definitions of data schemas should come from the java classes themselves, not config files or existing databases.
- Sophisticated mapping. Persistent classes should not just contain simple values that map directly to a table. They should also be able to deal with object reference, aggregation, composition, collections/maps, embedded types, inheritence, circular dependencies, etc.
- Orthogonal entry point. The view of the database world should be as simple as a hashtable. A single object represents the database with get() and put() like methods.
- Performance. Developers should never have to break out of the O/R tool because of performance. In fact, it should be *faster* to use than many hand rolled persistence schemes as it hides the complexities of caching and lazy loading.
- Simple querying. It should be easy do things like 'find me all employees with a salary of x', or 'all people who orders totalling over x'.
- Transparent database management. The tool should be able to look at your object model and find out what changes need to be done to the database schema to support it (and optionally make the changes).
- State and behavior should live together. Classes should encapsulate both. For example, to perform an operation on a person, you should call Person.doStuff(), not PersonManager.doStuff(PersonData).
- No fuss setup. Adding the persistence tool to your application should be hassle free.
Sounds like a tall order - it is. But unless you happen to be writing a persistence tool, it's not your problem. If you can find a tool that meets these criteria it makes it incredibly simple to develop.
If you're using a persistence tool already, go count how many of the above criteria meets yours.
As for ROI. Assuming the above criteria are met, the learning curve is only something you have to go through once and should be minimal. Sit down for a few hours, read some tutorials and your set to go. There should be very little constraints imposed - and the advantages should by far outweigh these. Even on the smallest of apps, I find the ROI on an O/R tool is excellent. For large apps, it's not no longer a nice to have, but essential.
SQL alone is not complicated. But building an application with SQL scattered around throughout it that's tightly coupled to a database schema can make app dev very messy very quickly. Something I prefer to avoid.
For the record, I use Kodo (my fav JDO implementation) with a few custom addons to complete all my criteria - it's a well supported commercial product that's affordable.
My 2 cents.
|
