Re: Mixing OO and DB

On 2 Mar, 19:47, Robert Martin <uncle..._at_objectmentor.com> wrote:
> On 2008-02-28 10:36:03 -0600, topmind <topm..._at_technologist.com> 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 (www.tpc.org) 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.

Why?

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