Re: OOP - a question about database access

"Bob Badour" <bbadour_at_golden.net> wrote:

> "Universe" <universe_at_covad.net> wrote:

> > "Bob Badour" <bbadour_at_golden.net> wrote in message

> > > "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message

> > > > "Robert C. Martin" <u.n.c.l.e.b.o.b_at_objectmentor.com> wrote:

> > > "Alfredo Novoa" <alfredo_at_ncs.es> wrote:

> > > > > >Objects like Employee, Customer, etc are completely
unnecessary
> > > > > >because that entities are already managed by the DBMS. You
only need
> > > > > >to map the database tables to visual controls like grids,
edits, etc.

> > > > > This might be true if the database application does absolutely
not
> > > > > processing of the data. If there are no business rules, and
the
> > > > > system does nothing more than add, display, modify, and delete
> > > > > records, then having entity objects may not be very useful.
On the
> > > > > other hand, as soon as you add any business rules, such as
field
> > > > > validation, or summary reporting, etc. you need a way to
separate
> > > > > those rules from the database. That's one very useful
application for
> > > > > OO.

> > > > What a pearl!
> > > > ...
> > > > If recognized OO writers show this "understanding" of the data
> > > > management issues, imagine the rest.

> > > Yep, it's widespread and piled high.

> > ... *please* explain *concretely* why an app that processes *outside* of the
> > dbms would not use > > separate types?

> Please explain how your demand has anything to do with what I wrote.

Not a demand, simply a request [note the *"please"*] in quest of furthering discussion to extend and deepen truth. Also I ended with: *"Be much 'Preciated, Elliott"*

The question likely makes sense to whomever wrote:
> > > > > >Objects like Employee, Customer, etc are completely
unnecessary
> > > > > >because that entities are already managed by the DBMS. You
only need
> > > > > >to map the database tables to visual controls like grids,
edits,

If it was you and you don't see the link, hey don't sweat it.

However seems Alfredo Novoa made the remark.

> > Can you guys explain why OO's support for polymorphism is bad, or not
> > useful?

> Why would I explain anything I never said? Can you explain why the sky is
> pink?

If you have never explicitly said that on comp.object, it was implicit to me in your explicit comments.

If you don't agree, c'est la vie. Your loss not ours.

> > Can you explain why using models that are more intuitive for both > > developers and clients should be avoided and disdained.

> I don't do that.

You don't explain why you make disparaging remarks about OO--you just make 'em? Whatever floats your boat, but most of us find this a key, worthwhile practice for this newsgroup. If you are anti-OO, you hang out here at times, and you "don't do that" explaining of your pov, then what's "that" you are up to?

> I encourage the use of the relational model, and I have > never disdained it. If you are suggesting that some primitive location-based
> computational model has usability advantages, please show us your empirical
> evidence.

There are few formal analyses that OO modelling is less complex and more intuitive.

However the empirical evidence that most advanced developers and IS/IT savvy clients generally find OO models more intuitive, and or less complex than models of other paradigms for the same given context is that they communicate this understanding.

Elliott

-- 
Though types are contextually based, they are **objectively true** for
the context.
-- 
Be bold, be artistically imaginative, yet scientifically grounded -- DO
GREAT  OO  MODELLING  WITH  OBJECTS  OF  ALL  TYPES!!