Re: Mixing OO and DB
Date: Tue, 4 Mar 2008 02:08:43 -0600
Message-ID: <2008030402084399097-unclebob_at_objectmentorcom>
On 2008-03-03 11:24:17 -0600, topmind <topmind_at_technologist.com> said:
>
>
> Robert Martin wrote:
>>
>> The mapping is coded in source modules, of course. However, the main
>> application has no source code dependencies on those modules.
>> Therefore they are easy to replace with dummies or alternate
>> implementations.
>
> The only change scenarios you seem to offer is testing.
It's one of the most useful since it's so general. Everything needs to be tested.
> Like I said
> before, one usually has a dummy testing database (sometimes called the
> "development DB") that mirrors the production database. We don't swap
> code, we swap DB's.
That can work in very simple situations. On the other hand I have a client who produces a huge project management system. They have thousands of different tests scenarios, each of which requires a different database setup. Swapping between those database is ferociously expensive.
> And, it's easier and more natural to type/move test data into DB's
> than set/gets. Mass set/gets are an ugly thing. Try using a reporting
> tool to print out test data that's in set/gets.
Who said anything about set/gets. You're right, they're ugly.
>> Sure it is. find_eligible_employees is at a higher level of >> abstraction than select * from ... and ... where ... < ... or ... ... >> ... ;
>
> Barely. Use a *comment* if need be.
Are you suggesting that every time you have an opportunity to create an abstraction you should use a comment instead? Surely that's a foolish and dangerous strategy. Don't use comments when you can express your intent in code.
> I am not going to use methods/
> routines as merely a glorified comment. Extra routines/methods creates
> clutter.
Unecessary comments *are* clutter.
> Again, use a comment if need be:
>
> // calc net pay
> netPay = earnings - deductions;
That comment is redundant, and therefore clutter.
>> Not quite. The app because an *application specific* DB. That's not >> half-assed at all.
>
> Existing RDBMS tools are usually sufficient.
Being sufficient, and being clean are two very different things. We'd like our applications to say what they mean as directly as possible. We don't want them to have to mumble through the dialect of a database implementation language.
> I don't want to have to reinvent all this sh8t from scratch.
Of course not. You don't re-invent it. You use it. You just *place*
> Plus, OO is navigational, and relational is superior to navigational
> in my opinion.
Blah blah. OO is not a DB. OO is not supposed to be a DB. The relational/navigational argument has no bearing.
>>> OOP 101: >>> >>> 1. RDBMS are Satan. >> >> That's actually a very foolish statement that flies in the face of an >> immense body of data. There are very few OO applications out there >> that don't make heavy use of relational databases.
>
> OO'ers see it as a necessary evil and don't have a choice because
> that's where all the data is. Many OO'ers want to toss RDBMS for
> OODBMS (commercial or roll-your-own).
You've created an enemy out of thin air. I consult on a *lot* of different projects. I simply don't see the attitude you claim is so pervasive.
-- Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 |Received on Tue Mar 04 2008 - 09:08:43 CET