Re: Mixing OO and DB
Date: Sun, 2 Mar 2008 11:28:28 -0800 (PST)
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