Re: Mixing OO and DB

Robert Martin wrote:
> 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.

Okay, but "Everyone should use OO because it's better for testing" is not that common a claim. Then again, what OO is good for changes every year or two.

>
> > 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.

Why? The devil is in the details. I have none here. What are they swapping between and why?

>
> > 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.

So if there are lots, storing test cases in a database can be a good thing, right?

>
> >> 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?

You are putting words in my mouth. I never said 'every'.

> Surely that's a foolish
> and dangerous strategy. Don't use comments when you can express your
> intent in code.

Sometimes a comment can do the job better, sometimes the code is sufficient. Experienced and thoughtful developers know when to use what.

>
> > I am not going to use methods/
> > routines as merely a glorified comment. Extra routines/methods creates
> > clutter.
>
> Unecessary comments *are* clutter.

Again, experienced and thoughtful developers know when to use what. If they are unnecessary, then don't use them. I've found a style that I think is "good", but I cannot guarantee that others think the same as me when they read them.

>
> > Again, use a comment if need be:
> >
> > // calc net pay
> > netPay = earnings - deductions;
>
> That comment is redundant, and therefore clutter.

Okay, bad example on my part. You're right on that one because it's redundant. Pair programming fixed a comment in this case :-)

>
> >> 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.

Bloating your code up to hide from SQL is hardly "direct". More methods to hunt through erases any gains you may get from wrapping it.

> We don't want them to have to mumble through the dialect of a database
> implementation language.

But being stuck with a specific app language is okay? I am not sure what you are asking for. It appears to be a double standard. Please clarify.

>
> > 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*
> it where it's most useful and not in the way.

Well, I disagree with your coding style. It doesn't work as well for me. If it works well for you, good. I'm not you.

Stop imposing your PERSONAL PREFERENCES on others. I know where I want my coffee cup, I know where I want my pencils, and I know where I want my comments.

It's like designing a report: everybody and their dog wants it a different way. One wants it color coded, another with black-and-white code markers so that he can copy it easier, another portrait so that she can put it in her binders, but another landscape so that there's more room for titles, etc. etc. etc.

Ai ai ai. Everybody's the goddam center of the universe.

>
> > 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.

Structures are structures. A graph of objects is a structure. Relational offers guidelines to such structures to produce some consistency and integrity. Navigational has nothing comparable so far. Someday it will be lumped in with Goto's as anachronisms of the past and people will laugh at OO like they do Gotos.

>
> >>> 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.

I would roughly estimate about that 30% of the OO'ers I debate want an OODBMS instead of an RDBMS. If your experience differs, so be it. I don't watn another anecdote fight.

>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Tue Mar 04 2008 - 18:42:05 CET