Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Robert Martin <>
Date: Fri, 2 Jun 2006 08:21:31 -0500
Message-ID: <200606020821318930-unclebob_at_objectmentorcom>

On 2006-05-31 12:00:56 -0500, Bob Badour <> said:

> Robert Martin wrote:

>> On 2006-05-30 17:31:10 -0500, Bob Badour <> said:
>>> Joe Van Dyk wrote:
>>>> Hm, I take it you're not a big fan of the Active Record pattern?
>>> Only a complete idiot would be. "Let's take something with the full 
>>> power of predicate logic and leave it with, um, restriction. Yeah, 
>>> that'll bring it down to the level we want!"
>> I have no idea why you say that.  The Active Record pattern 
>> ( is just a 
>> way to organize some application code in a way that provides access to 
>> the database beneath.  It does not restrict predicate logic in any way.

> This is how you prove that you are not only ignorant but stupid as well.


> How do you join two active records?

You make a third active record which represents the join, and you embed within it the SQL that executes the join. The active record is just the projection of the join into the application.
> Fowler is an idiot.

Is this your answer to everything? Are you so ultimately intelligent and all powerful that you can deride everyone else?

> Given two formal systems: one very powerful system operating at the
> level of intent and the other very low-level system obscuring intent,
> his solution is to cripple the powerful one down to match low-level one.

Firstly this is not HIS solution. The book he published was an accumulation of patterns that he has observed to be useful in application development environments over the last several years.

Secondly, the pattern does not cripple the DBMS, it employs it and projects the results of its operations into a form that is convenient for the application programmer to use. Repeat, there is no crippling here. The active record does not need to be 1:1 with the tables.

>> I'm not a big fan of this pattern for most applications because it 
>> couples the database logic and the business logic into a single class.

> Here, you once again prove your ignorance.

You are repeating yourself rather a lot, and not very creatively. I suggest you invest in a cookie program that generates random insults that you can then wire into your news reader so it can prepend the insults to the beginning of each of your paragraphs. Then you can appear to be creatively insulting without having to work at it.

> The database logic is necessarily the business logic, and predicate
> logic (ie. the relational model) is the best formalism we have for
> symbolic manipulation of logic statements. You prove your stupidity by
> choosing to throw away predicate logic in favor of an ad-hoc construct
> invented for creating large, unpredictable state machines.

Bob, nobody is throwing anything away. The data from the database are being projected into the application so that the application can manipulate it into other forms.

Now perhaps you think the DBMS should be doing all the manipulation, web page generation, client server control, third part system interaction, report generation, etc. I will grant you that there are some application domains where the entire application can, and even should, be written in the DBMS. However, that is not the choice that most system designers make; and for good reason. It is hard to get a DBMS to draw network diagrams on a GUI, or do Finite Element Analysis on a huge manifold, or construct binary trading packets, or...

>> I prefer Table Data Gateway structures that allow me to put the DB 
>> related code into one class, and the business rules in another.

> Here, again, you choose to forego the power of predicate logic for
> expressing business rules in favor of the ad-hoc construct invented for
> creating large, unpredictable state machines.

I don't suppose you are referring to Horn clauses, are you? Frankly I'm having a hard time decoding your statement. I know this doesn't surprise you since I am such an ignorant and stupid fool, but an example might help.

Could you show me how you would construct a credit request packet from a customer record and send it to the credit service, and then process the response? Just for the sake of argument we'll keep the packet simple. The request packet is just a simple SSN encoded in BCD in five bytes. The response is two bytes that contain a binary number whose value ranges from 0-999. You send the request to port 884 of, and it will reply within 2 seconds. If it doesn't reply within 2 seconds you need to retry. After the third attempt, you need to declare an error in the current transaction and create a log file entry. Given a valid reply, you set a flag in the customer record to ACCEPTED if the returned value is > 500, otherwise you set the flat to REJECTED.

>> It does not take a "complete idiot" to value these design patterns.

> Okay, I exaggerated a little. Any sort of idiot might value these
> design patterns and not just a complete idiot.

Ah, a spark of creativity! Well done.

BTW, cookie programs are pretty common, and very old. You can probably find one written in C and get it to work on any machine you currently own in a matter of minutes.

Robert C. Martin (Uncle Bob)  | email:
Object Mentor Inc.            | blog:
The Agile Transition Experts  | web:
800-338-6716                  |
Received on Fri Jun 02 2006 - 15:21:31 CEST

Original text of this message