Re: OOP - a question about database access
Date: Fri, 7 Nov 2003 16:40:53 -0500
Message-ID: <9945e$3fac1163$428681c3$941_at_msgid.meganewsservers.com>
"Bob Badour" <bbadour_at_golden.net> wrote in message
> > "Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b_at_objectmentor.com> wrote
in
> "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message
> > > >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!
> >
> > Sorry for the crossposting again, but I find things like this
> > interesting in order to understand the current state of the IT
> > industry.
> >
> > If recognized OO writers show this "understanding" of the data
> > management issues, imagine the rest.
> Yep, it's widespread and piled high.
While RCM has definite problems, please explain *concretely* why an app that processes *outside* of the dbms would not use separate types? I don't get much from pure sarcasm.
Can you guys explain why OO's support for polymorphism is bad, or not useful? Can you explain why using models that are more intuitive for both developers and clients should be avoided and disdained.
Be much 'Preciated,
Elliott Received on Fri Nov 07 2003 - 22:40:53 CET