Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 13 Jun 2006 05:35:18 -0700
Frans Bouma [C# MVP] wrote:
> Robert Martin wrote:
> > On 2006-06-01 23:09:37 +0200, Bob Badour <bbadour_at_pei.sympatico.ca>
> > said:
> > > phlip wrote:
> > >>
> > >> An application should have its SQL statements in only a few
> > modules, and >> all others should be SQL-free.
> > >>
> > >> Note in my statement, you can replace SQL with GUI, XML, ORB, etc,
> > to >> generally the same effect. The point of modules is to isolate
> > and >> encapsulate.
> > >>
> > >> Is that so hard?
> > >
> > > Define: few
> > The best answer is "one". We would like all the SQL to be placed in
> > one module, or one group of modules that are all related. More
> > importantly we want that module (or that group of modules) to be
> > independent. No other modules in the system should know that it
> > (they) exist(s). All dependencies point AWAY from the SQL modules.
> > |App Modules|<------|SQL MODULE(S)|
> erm, shouldn't that arrow be in the opposite direction? I mean, how
> can an app module function if it needs to consume data from a
> persistent storage when it doesn't know of a module which can provide
> that data for him? But this might be an interpretation error from my
> part: I interpret your diagram as : SQL MODULES are depending on App
> modules, something I don't see as logical as A <--- B suggests that B
> uses A thus A <---- B is a using relationship. Or am I missing
> something? (could be, my UML is a little rusty ;))
Hello, spoken to you at the developmentor group.
no, this is an example of Mr Martin's (errant) DIP notion.
The normal model of design would be to go.
App----->data interface<-------SQL modules.
for some reason Mr Martin is obsessed with putting the data interface inside the app.
(we have agreed to differ about this, lifes too short.). Received on Tue Jun 13 2006 - 14:35:18 CEST