Re: Mixing OO and DB

From: frebe <>
Date: Sun, 2 Mar 2008 11:19:34 -0800 (PST)
Message-ID: <>

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';  

Only for people not educated in SQL. Understanding what "Employee.find("Bob") ", does, is actually impossible without the implementation of find() availible.

> In any case, once you have the method, you can polymorphically replace it
> with test methods etc.

The SQL statement "Select * from Employee_Table where Name = 'Bob'", may be run against virtually any SQL type database, even in-memory databases.

> > Plus, most apps don't switch database vendors.
> True, but most apps need to be tested, and the testing independently of
> the DB can be a significant advantage.

If testing without the DB should be interesting at all, it means that you don't use the db for application logic. If you use it as a dumb perstistence mechanism, it might be interesting, but hardly an advantage.

> > OOP here is a solution looking for a problem.
> Not at all.  The problem is very simple.  Run 10,000 business rule
> tests through your application in under a minute.

Once I read about a TPC ( made on a laptop (year 2005), and I think the result was 8000 transactions per second.

> Doing this with the datbase in place is a lot harder than polymorphically replacing the
> database.


//frebe Received on Sun Mar 02 2008 - 20:19:34 CET

Original text of this message