Re: Mixing OO and DB

On 2 Mar, 20:01, Robert Martin <uncle..._at_objectmentor.com> wrote:
> On 2008-02-28 12:03:06 -0600, frebe <freb..._at_gmail.com> said:
>
> >> 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';"
> > );
>
> > Why is the first line better than the last line?
>
> It's smaller, more communicative, and can be polymorphically deployed.

Both are one-liners. It is only more communicative if the reader can't read SQL. The SQL can be deployed to a lot of databases.

> >> 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.
>
> > And for queries we don't use on a regular basis? We can use "raw" SQL,
> > or?
>
> Write methods for them.
>
> >> So we have not lost the power of the flexible query language.
>
> > If you still allow "raw" SQL for queries not used on a regular basis,
> > the power is not lost. But if you must have a find_by_xxx, for every
> > possible select statement, the power is lost.
>
> Not at all.  All we are doing is giving each query a name.  That name
> is the name of the method that is implemented by the SQL.  This allows
> the programmer to commnicate the *intent* of the query, rather than
> it's implementation.

What stops you from creating views when suitable? If you force programmers to put every unique SQL statement inside a method, they will soon hesitate writing new SQL statements, and try to reuse old ones that doesn't fit, but still does the job.

> e.g. Employee.find_all_eligible_for_retirement() is a lot better than a
> long and complex SQL statement.

create view eligible_for_retirement, is even better. But you contine to ignore views....

> > What is the benefit with hiding SQL from the bulk of the application?
>
> You can provide test implementations that don't use the database, but
> allow you to quickly test business rules.

If the business rules (eligible_for_retirement) is in the database, the test would be pretty useless.

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