Re: Relational-to-OOP Tax

Decoupling SQL statements may or may not increase the total
number of lines of code, depending on the size of the SQL statements
and the number of times they are reused.

Forcing all SQL statements into functions instead of only putting them
into functions when suitable, will always increase LOC.

As discussed elsewhere in the thread, even the hard of learning
Mr. Jacobs admits that lines of code is not a sufficient measure.

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.

The techniques used to decouple components and avoid big balls of
mud offer significant benefits, particularly in addressing
non-functional requirements.

Can you prove this claim?

Maintainability and extensibility are two NFRs that come
immediately to mind. Clean code is easier to maintain and extend.

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)

Reliability is increased when code is designed to be easily testable,
another characteristic of clean code.

Doesn't the SQL statements need to be tested too?

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?

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

Do you have some examples of this?

Are you arguing that clean, well-designed code does not have
quality benefits?

No, but creating new functions with only one statement or functions
that are only called only once, doesn't create cleaner or more well-
designed code.

The benefits of decoupling SQL has to be considered unknown until
someone can prove them. But the disadvantages (more bloated code)
are easy to prove and has to be accepted as facts.

The benefits are readily apparent to anyone who has developed any
large, or even mid-sized, enterprise system.

Then it wouldn't be any problem for you to prove them.

The "bloat" you claim
has yet to be demonstrated when comparing like with like rather than
your naive lines of code metric.

If the bloat if obvious in a very small example, why wouldn't it be
obvious in a larger application?

/Fredrik

.

Relevant Pages

  • Re: Relational-to-OOP Tax
    ... Clean code is easier to maintain and extend. ... Doesn't the SQL statements need to be tested too? ... Isolating it from the application functionality makes ... The decoupling you are talkning about is only about creating extra ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... depending on the size of the SQL statements ... Regardless if your code contains SQL statements or not: ... insert into employee values ... It is cleaner when createEmployeeis more realistically imagined: ...
    (comp.object)
  • Re: Better Coding 2 SQL Commands
    ... It works but cleaner would be better! ... DoCmd.RunSQL (MySQL) ... It's not unreasonable to have to use two SQL statements to do that, so I don't see any obvious way to combine them. ... Please feel free to quote anything I say here. ...
    (microsoft.public.access.gettingstarted)
  • Re: Relational-to-OOP Tax
    ... Doesn't the SQL statements need to be tested too? ... You haven't demonstrated a need to test them in isolation. ... The decoupling you are talkning about is only about creating extra ... function addFooAndBar(foo, bar) { ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... you agree that decoupling SQL statements from the rest of the ... Clean code is easier to maintain and extend. ... But the disadvantages (more bloated code) ...
    (comp.object)