Re: Mixing OO and DB

On Mar 2, 6:45 am, Patrick May <p..._at_spe.com> wrote:
> If you have SQL littering your application code, all of that has to be
> changed and retested.  

This is one of the most common misconceptions in OOP world. 10 years ago I had an experience rewriting a legacy telecom database application (-- applications do change don't they?) The original was C+ + and ODBC (-- speaks a lot about "legacy" definition, doesn't it?) and the shiny new one was in Java. Being little more ambitious than the project required I decided to roll over my own ORM framework based on reflection. It readed table/column definition from the classes. (Yes, if there is a hammer, everything else looks like a nail.)

The original project has database access in embedded SQL all over the places. Certainly embedded SQL looked like an eyesore, bit it was so easy to understand what an each piece of the code did! Reflecting back to my "framework" design the logic becomes hidden under some obscure function (oops, method) calls.

Couple years later I took a glance into a "professional" ORM tool. After couple of introductory pages explaining simple stuff I came across a table "summarizing" all possible kind of mappings between objects and tables/views. There were twenty something different mapping types! My natural reaction was "There is no way learning this junk is worth any effort. I'll stick up with JDBC and map objects and relations manually -- this is simple enough."

In a word, if you are database application programmer your time is better spend learning database fundamentals and best practices (which are quite obvious if you have learned fundamentals).

Part 1: http://www.youtube.com/watch?v=40Lnoyv-sXg
Part 2: http://www.youtube.com/watch?v=GbZgnAINjUw
Part 3: http://www.youtube.com/watch?v=y70FmugnhPU