Re: Mixing OO and DB
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 02 Mar 2008 21:21:30 -0400
Message-ID: <47cb529b$0$4033$9a566e8b_at_news.aliant.net>
>
>
> 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
> Forget about ORM.
Date: Sun, 02 Mar 2008 21:21:30 -0400
Message-ID: <47cb529b$0$4033$9a566e8b_at_news.aliant.net>
Tegiri Nenashi wrote:
> 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
> Forget about ORM.
Excellent video series except I found the audio track painful to listen to. Received on Mon Mar 03 2008 - 02:21:30 CET