Re: Relational-to-OOP Tax

More lines of code takes longer time to write. More lines of code
makes the code harder to read.

This is not always, or even often, the case. Highly coupled
big balls of mud that mix different concerns are more difficult to
understand than well-factored, clean code.

But nobody have proved why separating all SQL statements would
create cleaner or more well-factored code.

Actually, several people have pointed out the value of separating
concerns. The retrieval, transformation, and use of data are
conceptually different; combining them in a single lexical unit
reduces the understandability of that unit.

Do you have pointers to where "several people have pointed out..."?

In relational algebra retrieval, transformation and use of data is not
conceptually different. A single select statement can do it all. The
messy code is caused by the fact that you insist to transform
relational data into object graphs. If you skip doing this you don't
have any conceptually different concepts.

In what what way is

createEmployee(x,y,z)

function createEmployee(x,y,z) {
insert into employee values (x,y,z)
}

cleaner than

insert into employee values (x,y,z)

Even in this simple example, the name of the function is more
descriptive than the SQL statement.

Really? It is just different syntax.

It can also be re-used without
exposing the database schema throughout the application.

And the benefits with that are....?

Horizontal and vertical scalability benefits from having clearly
defined, decoupled components.

The decoupling you are talkning about is only about creating extra
layer inside an existing process. How can scalability benefit from
this?

Not at all. I'm discussing decoupling in the general sense,

I am not. Decoupling in a general sense have many benefits, but you
can't decouple everything from everything. Decoupling has also a cost
and that cost has to be compared to the benefits.

of which encapsulating SQL is only one, albeit important, aspect.

This is what we are talking about in this thread.

Both
horizontal and vertical scalability benefit from the existence of
decoupled, well-encapsulated components.

What is a well-encapsulated component in this case? Are you talking
about EJB beans or something here?

Security is easier to implement and prove when components have
single responsibilities.

Do you have some examples of this?

One of the primary difficulties with implementing security
correctly is the difficult to understand interactions between complex
components. Having a single responsibility for each component
simplifies analysis and testing considerably.

Is this an example?

/Fredrik

.