Re: OO versus RDB

From: Frans Bouma <>
Date: 30 Jun 2006 07:57:12 GMT
Message-Id: <>

topmind wrote:

> > That is, persistence is something outside the
> > realm where objects behave. No behaviour, no objects.
> In some views of OOP, the distinction is blurred. is a "getEmployee()"
> method behavior or data? It might be merely a behavioral wrapper
> around data, but if the internals are not visible (which
> encapsulation is sometimes said to do), one does not know. For
> example, "voteCount()" may actually loop thru all votes to compute
> the total. Or it may simply grab a value from an existing object or
> structure. One cannot tell without looking at the internals.

        as you used Java-style casing, I pressume getEmployee() is the getter for a 'property' called Employee, like myOrder.Employee which returns the employee who filed the order?

        For the caller it might indeed be a question what happens when you call the getter for Employee: is the employee lazy loaded from the db, or do you get the data handed to you directly because an in-memory representation of the entity data exists?

        Though is that really relevant for the caller? IMHO no, because it comes down to the fact that if the class writer followed proper guidelines, you wouldn't have expensive property getters and cheap methods but the other way around.

        Furthermore, if the behavior would be outside the object, you'd have to call some routine to get the data out of the object, AND to manipulate the data for example. That's of course doable, the thing is: is it wise to do that? In some situations it might, in others it might not, because it splits data and behavior which could lead to errors, or unmaintainable software, as you have data and behavior definitions spread across your application. Though how far should one go in merging them together?

        That's IMHO depending on the ideas you think are valid: some say: ALL of it should be in the class containing the data (pure DDD) while others say: No, all the domain specific code should be in stateless classes consuming rather behaviorless objects (Soa/webservice world)

         If you listen to either group, they claim both they're right and the others are aggrandizing idiots. Of course, some personality in cdt will say "They ALL are!", so let me save him the trouble replying ;)

> It could be said that OOP provides behavioral interfaces. But this is
> not necessarily the same as saying objects are behavior or require
> behavior.

        If someone claims an object IS behavior that someone indeed should re-think his/her statement. Requiring behavior is IMHO also a bit farfetched, though if all classes don't contain behavior you effectively could call it a non-OOP procedural program like a C program working with structs.


Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website:
My .NET blog:
Microsoft MVP (C#) 
Received on Fri Jun 30 2006 - 09:57:12 CEST

Original text of this message