Re: Mixing OO and DB

From: David Cressey <>
Date: Mon, 03 Mar 2008 12:59:57 GMT
Message-ID: <hDSyj.5682$Td2.4579_at_trndny08>

"Bob Badour" <> wrote in message news:47cb2504$0$4034$
> frebe wrote:
> > On 2 Mar, 19:47, Robert Martin <> wrote:
> >
> >>On 2008-02-28 10:36:03 -0600, topmind <> said:
> >>
> >>>>Of course we can implement other kinds of 'find' methods.
> >>>>find_by_date, find_by_salary, etc, etc. Every different query we use
> >>>>on a regular basis, we can create a verb for in our DSL. That verb is
> >>>>a function call of some kind.
> >>
> >>>Such only makes sense if you do the same kind of query in *multiple*
> >>>spots. One-usage wrappers are a waste of code in my opinion and just
> >>>creates tedious red-tape accessor clutter.
> >>
> >>Not if they are explanatory. Employee.find("Bob") is a lot easier to
> >>understand than Select * from Employee_Table where Name = 'Bob';
> How exactly does Employee.find(string) inform the reader that the method
> will return a single employee with a matching name? People understand
> things better when they are informed.
> > Only for people not educated in SQL. Understanding what
> > "Employee.find("Bob") ", does, is actually impossible without the
> > implementation of find() availible.
> I would agree that we can do better than SQL, which I find kind of wordy.
> For example, I can imagine useful relational syntax where the following
> would do:
> (Employee where Name = "Bob")
> or even
> {Employee | Name = "Bob}
> [snip]

I agree with you concerning wordiness. However, I'm going to go in the opposite direction in just one case. "Select * from employee" and the single word "Employee" in your two substitutes is bound to the definition of employees, specifically its components.

If someone comes along later and does an "ALTER TABLE Employees ADD COLUMN..."
The meaning of "Select *" would be altered. In this sense "Select *" is more data dependent than the equivalent construct, listing each of the columns instead of using the wildcard. Believe it or not, I've actually seen cases where using "select *" in application code created data dependencies that were not managed well.

The trouble with list all the columns is, of course, that it's even wordier. Received on Mon Mar 03 2008 - 13:59:57 CET

Original text of this message