Object Relational Mapping

Enter a topic name to show or a new topic name to create; then press Enter

.

Summary

thoughts on usins OR mapping

I was asked for my opinion on Object Relational (O/R) mapping I replied with a long email. Here's more or less what I said:

Pro's

1) Allows developers to work with a single programming model (objects)

This is useful if you have developers that don't understand database programming or you want to tightly control who codes the SQL.

2) Provides a data access layer to isolate and decouple the business logic from changes to the database

When the business logic of any application gets complex, a common design pattern is to create a business data entity model which is manipulated by a business object model. The data entity model is a logical abstraction away from the database logical/physical model that makes more sense for the business objects to manipulate. Things like type validation and integrity checks can be encapsulated by the data entity model while the business objects can concern themselves with the real business logic.

Con's

1) Isolates the developer from database programming

A database can do wonderful things and I would argue that any middle-tier developer should understand databaseprogramming quite well. Indeed one of the big killers of performance I regularly saw was numerous unnecessary database calls. For any given server call, the developer should have an idea of the entire SQL trace and context that his code runs in. Well, at least someone on the dev team needs to do this! Yes, this gets difficult as the complexity of the middle-tier grows.

2) Data access layers are dangerous

Certain logic is best executed on the database and not in a middle-tier. Even if you want database portability, there is often some amount of stored procedures and integrity/validation checks that ought to stay on the database and be rewritten for each port.

Note that there's a difference between trying to isolate yourself from database changes and database portability. With database

portability, you avoid taking advantage of any database features that are not common. This is generally only really needed by ISV's. Most projects just need to have some protection against schema changes. Using VIEWS is a typical strategy. This still means that database features can be fully exploited.

A data access layer also encourages a developer to implement features on the app server rather than get it implemented inside the data access layer. It depends on what the dev process/religion is like. In the worse case, I've seen developers writing manual JOIN's on the app server rather than the database. Arrgghh!

3) Too many objects

The creation and destruction of objects gets expensive on highly scalabled server apps. Fine-grained object-oriented middle-tiers don't perform well and O/R mapping encourages it. How collections get implemented is critical. A naive implementation will try and instantiate every member of a collection.

4) Sloppy transaction design

Object-oriented design and transactions don't mix very well. How the O/R mapping handles a transaction involving multiple objects needs to be carefully examined. Are there unnecessary transactional reads? Can lower isolation levels be used? Can transactions be controlled at the stored-procedure level? Indeed, how do transactions get controlled?

Recommendations

a) If you need very high performance or scalability, I would avoid O/R mapping completely. If you use OO, make it large-grained. It's critical to keep the memory pressure on the heap down.

b) Use O/R mapping if you have a lot of complex business logic and need the data entity/business object pattern.

c) Use a good tool to generate the O/R mapping for you.

If you use O/R mapping, make sure someone is analyzing the SQL trace for each server request and there is a good process in place for moving appropriate logic into the database. Avoid redundant queries and make sure the architecture/design allows the sharing the results of queries. Pay particular attention to transactions to make sure they are as short as possible and redesign the objects if need be.