Re: Mixing OO and DB

From: topmind <topmind_at_technologist.com>
Date: Thu, 28 Feb 2008 08:36:03 -0800 (PST)
Message-ID: <d85bf04c-6960-48c7-bb75-a5c794de460a_at_u10g2000prn.googlegroups.com>


Robert Martin wrote:
> On 2008-02-26 15:28:43 -0600, topmind <topmind_at_technologist.com> said:
>
> >> I know. And yet it's not a big stretch to different kinds of
> >> databases. If the application uses a simple API to access it's data,
> >> then that API can be seperated from the application by a polymorphic
> >> interface, and dummy databases of a different kind can be substituted
> >> in.
> >
> > A "simple" API is going to replace a sophisticated and powerful query
> > language? I don't think so.
>
> Don't be silly. Of course it can. That's what software is all about!

  doMagic(thinAir);

  ;-)

>
> One of the roles of good software design is to hide complexity. We
> take somethign complex, like a robust query languqage, or a tricky IO
> driver, or a fancy third party API, and we hide it behind a simple
> interface that is specific to our application.
>
> In effect we are creating a domain specific language at the high levels
> of our application. That DSL is composed of functions that hide the
> complexity of what lay beneath.
>
> So, for instance, if we must fetch an employee record frequently in
> various parts of our application it is better to use a function like
> this:
>
> Employee e = Employee.find("Bob"):
>
> Than it is to use raw SQL like this all through our app.
>
> DataRow e = exec("Select * from EmployeeTable where name = 'Bob';");
>
> The SQL is still there, mind you, it's just buried behind the 'find' call.
>
> 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. I see code like that an ask to review to contract to see if the programmer is paid per line of code.

It comes across as "SQL is bad because it is not OOP".

>
> So we have not lost the power of the flexible query language. We still
> have it, and we still use it. But we also hide it from the bulk of the
> application.
>
> That allows us to create a polymorphic API below which we can swap out
> different database implementations, or even stubs and dummies .

No it wont. Plus, most apps don't switch database vendors. A costprobability  study will usually not favor it unless you know in advance it is likely. And if you know in advance, you can write more generic SQL to reduce the need to change it.

OOP here is a solution looking for a problem.

>
>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Thu Feb 28 2008 - 17:36:03 CET

Original text of this message