OODB & RDBMS - and if that wasn't enough: Anemic & Rich Domain Model
jrwest and I have a little debate going on, which I enjoy very much. Here’s my reaction on his recent post.
The web is based on the sharing of information. Commonly, that information is stored in databases. The strict rules we impose on our data is a matter of security.
I agree with you: it’s all about information. I’m seeing it from the core / backend developer’s perspective. The data used in our algorithms is object oriented. The data stored in our storage is relational. This is the main point: two different models that need to be mapped.
In an anemic domain model, using an OODB does not mean that you can get rid of the persistence layer, since although you could hang your behavior free object tree into the database without any problem, you should of course still decouple the database entity classes from the entity classes of your implementation.
You just don’t need to map between two whole different kinds of data representation.
In an anemic domain model, where you have a strict segregation of entity, control & boundary, you can just use a mapping framework to do so. For example, you define some rules to fill the db objects with the core objects or vice versa.
You still map your data, no big deal. It just got easier.
By assuming our application handles all matters of data security is a major weakness in my opinion.
That is a critical point. In fact, you may embed you OO database within your code. But you may as well set up your own server to run the OODB & we’re on the save side again.
Let me distract the audience by another thought:
In a rich domain model (short intro), things start to get interesting - since you don’t have empty data containers (entities), but proper real OO classes that have both attributes and behavior, you actually have both behavior and data together in a single class.
Yes, I’m serious - and Martin Fowler is, too ;-).
Rich Domain Models are a real challenge in general. You have to think about how to cut the behavior. Should a user object be able to buy an article in your shop? Yes. OK, that was an easy one. But should he be able to create himself? Hm… tough one. There’s much pro and contra and there is not the single Right Thing that your design will have to look like. You really have to “think more ” to design a nice rich domain model compared to the popular anemic one.
One major decision you’d have to consider: should the object be able to store itself into the database?
I’ll leave you with that one ;-).
So, let’s get back to the main subject of the debate & summarize the main facts:
- mapping object structures into relational structures is a big hazzle
- mapping object structures into object structures in the OODB has less hazzle-potential
- using an OODB does not mean that there’s no transaction control / an ACID concept
I brought this up a while back but no one would take me up on it. Perhaps you’d be interested in debating this with me. I see your points about advantages that OODBs present where multimedia and some other unique scenarios are concerned. I even see how people enjoy breaking out of the strict rules of RDBMS. Maybe I just haven’t had a chance to see the light but I feel that the secondary, even repetitive layer of data integrity built into classing relational models is very important. Why? The web is based on the sharing of information. Commonly, that information is stored in databases. The strict rules we impose on our data is a matter of security. One of the up most importance. By assuming our application handles all matters of data security is a major weakness in my opinion. Think about where else we use two layers of security to protect our data. I have one password to access my laptop and another to decrypt different directories in my drive as well as my home folder. Your thoughts? Would really love to turn this debate into a full post by the way if your interested and we can work out some free time.