21 June 2003

To ORmap ORnot To ORmap

The discussion on OR mapping and the use of datasets vs. custom domain entity objects is running hot on Andres blog. Frans Bouma and Jesse Ezell took a look at my last entry before they moved in at Andres place.

I agree with Frans refinement of what OR mapping _is_. It will never ever solve concurrency and so forth, nor is it its purpose. The "struggle" I used as a picture refers to the effort to create and use these facades that portraits objects as OO whilst they really are copies of dbdata, most often to handle complexity. 

What I want to get at here is that there maybe should be some kind of scale for this issue. It seems to be agreed that the complexity in the domain model dictates how "heavy" entityobjects you should have. So with low complexity use "light" portable, message-centric entity objects, here all logic lies in the service objects. In the other end of the scale you have custom entity objects, with complex relationships, possibly complex built-in validation, serialization and so forth. In this scenario the a lot of business logic is encapsulated in the entityobjects and their relationships which eases the complexity of the service objects.

I feel there are two outer-points here, but I can't quite see the line (scale) between them clearly. Anyone up for a definition-contest?

Comments

# Andres Aguiar said:

It's very difficult to draw the line.

Domain models are sexier, and if you believe that more complex logic can be handled that way, when you start a project you always try to protect yourself building a domain model, because you'll never how it will evolve. Is probably breaking the 'do the simplest thing that can possibly work' rule, but as it's quite difficult to refactor a non-domain model to a domain model, I understand it.

The challenge is to find better ways to use a message based approach that skips the domain model and uses the database as the model. That's what we are trying to do with DeKlarit.


Saturday, June 21, 2003 5:41 PM
# Paul Gielens said:

Andres, interesting. You are so totally right on the 'do not' rule, but the database as a model... In our old MES system we did something simular and it became a nightmare. Little modifications broke various other parts and eventually resulted in a crappy hard to maintain or extend application. Systems with a database as the model require a fairly amount of upfront design with little or no change of requirements. This is imo not the way we should be engineering software anno 2003.

Saturday, June 21, 2003 10:08 PM
# Andres Aguiar said:

I do not believe in upfront design. That's why DeKlarit supports database refactorings and why I'm suggesting that you should code using structures that more innmune to database schema changes that the domain model.

I'm sure you will need to change your db schema during the lifecycle of the application.

Sunday, June 22, 2003 11:18 AM
# Mads said:

I will need a _lot_ of convincing to agree that the db model should be used like that. And I've had great results with moderate upfront design aswell. A database structure are designed to optimize storage. Your domain / design /impl. model should optimize runtime and maintenance. Would you decorate your appartement like a warehouse for your wedding? :-)

Monday, June 23, 2003 12:43 AM