Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: frebe on 19 Feb 2007 12:26 > > The question is if the disadvantage with bloated code, is smaller than > > the possible advantages with wrapping all SQL statements in a separate > > layer. So, a good argumentation why wrapping a standardized language > > would increase portability, or why yet another layer would increade > > modularity, would be welcome. > > If (most of) my files containing Java code do not > hardcode SQL in them I can change my SQL without > a chance of breaking my Java code, and vice versa. Are you saying that if you change your SQL statements, you don't have to change the code in the host language? Doesn't that depends on what kind of change you are doing? Why is this easier if you separate all SQL statements into a special layer? > I might have to do this when I switch my database > from MS to Oracle for example. SQL have a rather high level of standardization. It is pretty easy to make an application only using SQL statements that works on both Oracle and as SQL Server. Frameworks like Spring also have functions that allows you to use vendor-specific features like sequences, in a vendor independent way. That fact that some SQL statements are different for different vendors, isn't an argument for putting all SQL statements in a separate layer. > Most programmers are either experts in SQL, or in Java, > but not both. Most programmers are able to use both a language like Java and SQL If you have hired programmers unable to do this, you have indeed have a problem. But incompetence isn't really an argument for a design choice like this. > If SQL and Java -code are kept in separate > files then each group of experts can work on their > respective files, and be responsible for the correct > functioning thereof. But for almost every small new feature, these two group have to interact with each other. The consequence might be that the Java guys uses existing methods that doesn't really fit, because they find it too hard to ask the SQL guys to create a new method for them. > Divide and Conquer! Put SQL-problem in its own file. > Let the SQL programmers take care of it. Yeah, it is always nice to have someone else doing the job for you. /Fredrik
From: frebe on 19 Feb 2007 13:06 > 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
From: Thomas Gagne on 19 Feb 2007 13:57 frebe wrote: >> 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. > You keep asking for proof without specifying the burden of proof. What burden of proof would require for structured programming to prove it is better to call functions than not to (as used to be the case) or that it is better to let a filesystem handle file-io than an application to manipulate disk structures directly (as also used to be the case)? Is the burden of proof really so different that you can't extrapolate your experiences calling functions or using open/read/write/close to manipulate files onto SQL? > >> <snip> >> 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) > It is cleaner when createEmployee(x,y,z) is more realistically imagined: insert into employee... insert into address ... insert into employeeAddress ... insert into employeeEmployee ... insert into calendarResource ... insert into payroll ... insert into planParticipant ... insert into benefitParticipant ... insert into dependents ... and when another table is created that must know about new employees the procedure can be updated without modifying application code. Or if employees can be added from multiple applications it is better to have isolated the code for adding them than to duplicate it. > <snip> >> 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. > Practically speaking that is rarely the case. And even if it occurred more often than rarely, it is a better design that allows one module/function/method to change independently of others that rely on it. -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
From: topmind on 19 Feb 2007 16:06 panu(a)nospam.com wrote: > frebe wrote: > > > The question is if the disadvantage with bloated code, is smaller than > > the possible advantages with wrapping all SQL statements in a separate > > layer. So, a good argumentation why wrapping a standardized language > > would increase portability, or why yet another layer would increade > > modularity, would be welcome. > > If (most of) my files containing Java code do not > hardcode SQL in them I can change my SQL without > a chance of breaking my Java code, and vice versa. > I might have to do this when I switch my database > from MS to Oracle for example. As I've mentioned before, this is not that common in practice. Shops tend to stick with a certain brand. And the effort to change masses of SQL is not that different between wrapped and non-wrapped if it does by chance happen. > > Most programmers are either experts in SQL, or in Java, > but not both. If SQL and Java -code are kept in separate > files then each group of experts can work on their > respective files, and be responsible for the correct > functioning thereof. When two programmers work on the > same file, neither is responsible. Couldn't one use a Patrick May style of argument and say that programmers *should* know both fairly well and if they don't, then get better programmers? Plus, smaller shops often don't have such a sharp division. > > In construction, if Masons, Carpenters, Electricians, > Engineers, all work on every problem together, regardless > of their expertise - don't move to that building. > > Divide and Conquer! Put SQL-problem in its own file. > Let the SQL programmers take care of it. > > -Panu Viljamaa -T-
From: topmind on 19 Feb 2007 16:23
Thomas Gagne wrote: > frebe wrote: > > But nobody have proved why separating all SQL statements would create > > cleaner or more well-factored code. > > > You keep asking for proof without specifying the burden of proof. What > burden of proof would require for structured programming to prove it is > better to call functions than not to (as used to be the case) or that it > is better to let a filesystem handle file-io than an application to > manipulate disk structures directly (as also used to be the case)? Is > the burden of proof really so different that you can't extrapolate your > experiences calling functions or using open/read/write/close to > manipulate files onto SQL? > > > >> <snip> > >> 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) > > > It is cleaner when createEmployee(x,y,z) is more realistically imagined: > > insert into employee... > insert into address ... > insert into employeeAddress ... > insert into employeeEmployee ... > insert into calendarResource ... > insert into payroll ... > insert into planParticipant ... > insert into benefitParticipant ... > insert into dependents ... > > and when another table is created that must know about new employees the > procedure can be updated without modifying application code. Or if > employees can be added from multiple applications it is better to have > isolated the code for adding them than to duplicate it. In that case I would agree, but because it is an *entire* task in itself, not just part of a task. But that is not the typical use of SQL. Plus, it is a bit of a suspicious design. In most cases there are CRUD screens to enter each of those *one* at a time. It is not common do update multiple entities like that all in one shot. First you create the Employee record and then press Save, then Benefit records and press Save, etc. One or two entities per CRUD screen is the norm. Nine is a freak. I suspect you are storing everything in OO structures first, which is unnecessary. > > <snip> > >> 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. > > > Practically speaking that is rarely the case. And even if it occurred > more often than rarely, it is a better design that allows one > module/function/method to change independently of others that rely on it. I bet I could find counter scenarios for any scenario you present. Changes come from all directions, not just from pro-OO books. > > -- -T- |