Re: Mixing OO and DB

"Robert Martin" <unclebob_at_objectmentor.com> wrote in message news:2008030214431664440-unclebob_at_objectmentorcom...
> On 2008-03-01 12:15:34 -0600, topmind <topmind_at_technologist.com> said:
>
> >> Now you're just being a twit. It is very straightforward to
> >> decouple application logic from the mechanism used to maintain the
> >> persistent state of that system,
> >
> > Here you seem to be using the DB as *only* a dumb filing system.
>
> No. The DB is a powerful data management and query engine. The
> application code takes the greatest advantage of that engine. But the
> code that controls that engine on behalf of the application is isolated
> into modules that are polymorphically decoupled from the main
> application.
>
>

It seems to me that this comment captures in a nutshell the basic disconnect between the DB crowd and the OO crowd. I'll confess that my perspective puts me firmly in the DB camp. But I'm trying to understand what the other camp is thinking (above the din).

I think it's a matter of perspective: what you see depends on where you stand.

Robert's comment is a succinct summary of what you might see if you stand inside an application, but outside all of the objects that are components of that application. In that case, isolating the SQL code into a single module achieves several goals. The first goal is that it localizes the maintenance requirement when the application must be ported to an environment that no longer supports SQL, or is modified in several other ways. The second goal is that it helps people who don't understand the data by isolating the code that they won't be able to read into a single module. There are other goals, but these two will do for now.

Before I move on, I have to give an opinion based on my own data-centric world view. If you don't understand the data, then you don't know what you're talking about. In short, I completely fail to grasp how one can understand a system in terms of "behavior" without understanding the data that the behavior affects. This is something that it's going to take me years of lurking in comp.objects to grasp. And I suspect that, based on the experience of people like Marshall Spight, that I'm going to conclude, at the end of the day, that behavior is not the holy grail of computing.

Now let met tell you my perspective: it's standing outside all the applications, and all the databases. Notice that I said databases, plural. There's no law that says that a system may not contain more than one database. However, there is a law that states, (I claim) that all the data in all the visible databases should conform to a single conceptual data model. Otherwise, the entire system is fragmented, from a conceptual data point of view, in ways that are practically impossible to manage. (I realize that a lot of real world situations are in exactly this situation, but my critcism stands.)

From this point of view, an application is a "capsule", in the sense that the folks who use the term "encapsulation" mean it. I can't see what's going on inside the application. There could even be databases inside some of the applications, and the data in those databases need not conform to the unified conceptual data model I described above.

From this point of view the comment Robert made, that provoked the response, is of no consequence. I don't care how the application is organized into modules until I "open the capsule" and start to peer into the internals of that application. At that point, I've shifted where I stand, and I've changed my perspective.

In my original perspective, the single thing that ties together all the applications and all the databases that collaborate by sharing data is just one thing: data. If you understand the data, and you understand the (observable) behavior of each of the applications and each of the databases, you can understand the system. Otherwise, you can't understand the system. Received on Mon Mar 03 2008 - 13:50:39 CET