Re: Mixing OO and DB
Date: Thu, 28 Feb 2008 08:55:19 -0600
Message-ID: <2008022808551975249-unclebob_at_objectmentorcom>
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!
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.
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.
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 .
-- 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 Thu Feb 28 2008 - 15:55:19 CET