Re: Mixing OO and DB
Date: Mon, 3 Mar 2008 19:27:26 -0600
Message-ID: <2008030319272680278-unclebob_at_objectmentorcom>
On 2008-03-03 07:04:54 -0600, "David Cressey" <cressey73_at_verizon.net> said:
> > "Gene Wirchenko" <genew_at_ocis.net> wrote in message > news:c95ns39k99v3qqoeuj33li6h5f1biqoean_at_4ax.com...
>> Robert Martin <unclebob_at_objectmentor.com> wrote:
>>
>> [snip]
>>
>>> Not if they are explanatory. Employee.find("Bob") is a lot easier to
>>> understand than Select * from Employee_Table where Name = 'Bob'; In
>>> any case, once you have the method, you can polymorphically replace it
>>> with test methods etc.
>>
>> Bah! It is just syntactic sugar and not very sweet at that.
>>
>> Now try finding Bob who works in Accounting:
>> select * from employee_table
>> where name='Bob' and dept='Accounting';
>>
>> Your go.
>>
> > I don't have the answer, but I predict that it will boil down to which > changes faster: the data, the behavior, or the data structure.
None of the above. It's just a matter of which is easier to read.
Oh, I suppose the function call has fewer data dependencies. It doesn't mention the names of the tables or the columns, allowing them to change without changing anyone who calls the function. But that's secondary to the simplicity of the name.
If the *intent* of the query changes, then a new function should be called -- one with a name that communicates the intent. So this technique does not protect you from changes in query intent. It does, of course, insulate you from different species of SQL, if that matters. It also insulates you from the actual database should you decide that's necessary for testing, or other reasons.
-- Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 |Received on Tue Mar 04 2008 - 02:27:26 CET