Actually if you put the business logic in the backend then you can have a
variety of UIs and tools accessing the data and not worry about some tool
going around the middle tier and screwing up the data. You can swap
languages etc. in the tool and still access/manipulate the data.
Jim
"tk" <theronk_at_charter.net> wrote in message
news:vjluj7beu7i195_at_corp.supernews.com...
> Hope I'm not getting on folks nerves here :-) Just wanted to ask for
more
> opinions as I'm picking up PL/SQL quite well. I've spent about 2-3 hours
> daily for the past few weeks and am just about finished reading (and
working
> out alot of examples) my 2nd PL/SQL book.
>
> I have an object-oriented programming background (ie, C++ and Java) for
the
> past 12+ years so I'm quite comfortable with the methodology. I noticed
> Oracle's newer support for Application Objects (ie,
> Polymorphism/inheritance)...
>
> A few questions:
> 1. What's the difference between an oracle object that supports
inheritance
> and an oracle object that are triggers, procedures, packages, datatypes,
> etc?? Do you refer to the object-oriented objects by a different name
than
> the regular database objects?
>
> 2. As neat as it is that Oracle supports this "newer" type of object
which
> allows subtyping, how many out there are *really* using this feature? I
> mean, what I'm getting at is that this promotes "business" logic in the
> database which is (by many *but* I'm nuetral so I'm not going to say this
is
> right or wrong) considered inappropriate (especially in a 3-tier
> architecture where the business logic should really be contained within
the
> middle tier). Many positions that I have worked on typically have the
> business logic abstracted from the database and the database serves as a
> means of persisting the data model rather than the application structure.
> In all cases, the data models are abstracted from the domain structure
such
> that the models and relationships between tables can still remain in-tact
> (with little to no change) while the business model (in the client or
middle
> tier) can continually go thru semantical changes. It just seems to me
that
> utilizing these object-oriented features within PL/SQL can be "slightly"
> dangerous as you're locking your business logic into the database. So the
> whole point of 3-tier architecture is to be able to swap in/out the client
> portion (switching the ui) and the db-portion (ie, switching database
> products).
>
> I can see in a situation where one is using something like Oracle forms
and
> the Database. In that case, maybe you don't have a true middle tier and
> then can offload business logic with PL/SQL.
>
> A few other Oracle gurus I have spoken to feel this way too. They say
"It's
> neat that Oracle supports this but it's not going to be utilized much as
> application logic should typically be abstracted from the data model".
>
> So what's the best way to use these Object-Oriented features of Oracle??
> (ie, the METHOD, TREAT, BASE-DERIVED) Sorry for the "windbag"
questions!!!
>
> thanks...
>
>
Received on Wed Aug 13 2003 - 22:11:44 CDT
