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?

3 Comments

  • 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.

  • 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.

  • 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? :-)

Comments have been disabled for this content.