Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Robert Martin wrote:
> On 2006-05-31 13:44:06 -0500, "Tony D" <tonyisyourpal_at_netscape.net> said:
>
> > Others have debunked a variety of areas in this post already but a few
> > bits caught my eye ...
> >
> > Robert Martin wrote:
> >> This statement is fascinating. It takes the view that the majority of
> >> the system is DB and that application code simply fills the cracks.
> >> The DB represents the bricks and the application code is the mortar.
> >>
> >
> > Applications come and go. Languages come and go. Character interfaces
> > came and went. Client-server came and kind of went. Batch applications
> > made a bit of a come-back in nice new clothes as web apps. And guess
> > what ? The database is still there. Where would that suggest we expend
> > our efforts ?
>
> On the domain that is changing, since that's where the "progress" is
> being made. I presume that you are glad that character interfaces were
> replaced.
>
> The point is that the majority of our effort is NOT spent on the
> database because the database does not do the majority of what needs to
> be done.

This is debatable. Like I said in another message, one can usually shift the burden to the DB if they *want*. It may not be 100% on the DB, but it can often get to around 90%. Few would agree that such is practical. But putting at least half of it on the DB and queries is not unrealistc. I know that many OO'ers don't like doing such, but that is the crux of the matter: personal design preference.

Putting biz logic/rules/indicators in the DB allows me to search, sort, filter, and query such info almost any way I please. If you put it into code, then you are stuck with the format and ordering of the code writer. Sure, there are code browsers, but they essentially are navigational database browsers. And highly prioprietary and language-specific navigational browsers that are still not as powerful as relational.

> > The biggest performance black hole in a
> > networked application isn't the database, or the transaction log, or
> > the PC client, or the disk drives - it's that gnarly chunk of wire
> > running from the server to who knows where to wherever the client code
> > is, and back again. The more goes through that chunk of wire, the
> > slower things go. Better to leave the data exactly where it is for as
> > much of the time as possible.
>
> I quite agree. Which is one reason that I question the ubiquitous use
> of database servers. Not that they aren't useful; of course they are.
> It's just that few people seem to question whether or not they should
> be used on a case by case basis.
>
> But I don't know how we got on this topic, since the topic of the
> original post was a question of application design structure. Towit:
> Do you agree that the design of an application program should be
> strongly decoupled from the DBMS, to the extent that the DBMS could be
> swaped out for a completely different technology.

I have dissagreed with this in another reply. If one weighs the costs and benefits like an accountant would/should, strong decoupling is too costly I have decided, unless you know there will be a need to swap vendors up front. Decoupling is not free; It creates back-and-forth editing work and more interface maintenence.

> Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com

-T- Received on Wed Jun 07 2006 - 21:57:41 CEST