Re: OOP and databases in the real-world
- From: "Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 28 May 2006 13:18:38 -0400
First, the OOP methodology for working with a database varies greatly. A
database is simply a storage mechanism for any kind of data. The OOP
solution to working with the data is dependent entirely upon the usage of
the data and the business requirements involved.
IOW, there is no one OOP methodology for working with databases, any more
than there is one OOP methodology for working with files, or one OOP
methodology for working with any other form of data, stored or otherwise.
OOP is actually less of a methodoloy than a paradigm. It is a way of working
with and thinking about programming, with a number of extensions to
procedural programming that aid in the organization and usage of the code.
It is important to remember that all programming is procedural at heart,
including OOP. OOP is no more an academic exercise than high-level
programming languages are an academic exercise compared to pure machine
language.
OOP is a continuation of a series of derived principles that began with
Assembler language, continued to high-level languages, and is similar to the
use of functions, procedures, and structures in high-level programming
languages like C. It is a set of tools that facilitates the creation,
debugging, and maintenance of increasingly large and complex applications.
It is an abstraction of abstractions. Once you train yourself to think in an
object-oriented way, its power is apparent, and its usage becomes intuitive.
The hard part is re-training the way you think about programming in general.
As someone who started out doing procedural programming with C, I can
certainly understand the difficulty involved in making this change in one's
programming paradigm. It is similar in many ways to the change in paradigm
involved in understanding the mathematics of Calculus, or vector-based
graphics versus raster-based graphics. But it is well worth the time and
effort involved, as it leads to an exponential increase in one's programming
power. At least IMHO!
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
This is, by definition, not that.
"Fred Exley" <fexley221@xxxxxxx> wrote in message
news:127jkhf56mvps43@xxxxxxxxxxxxxxxxxxxxx
I have a traditional application using a database and procedural code that
works fine. I'm re-writing it using the OOP methodology, just to see how
this may be the better way to do things. I think I've got a pretty good
grasp of the three pillars of OOP, and have objects properly defined using
inheritance, encapsulation, etc. as appropriate. Now it's time to do some
processing using real data, and the data resides on a relational database.
As best I can gather, the preferred OO way to do this in general is to:
Write a utility routine to load the data from the database into their
respective objects.
For tables in the database with a master/detail relationship (i.e., Order,
Order Items tables), represent this in OOP by creating another class, an
intersect object, that relates one Order with one Order Item instance.
Create yet another class, to be used as a container for these intersect
object items, using an ArrayList (to make use of that objects built-in
methods; insert, update, enumerate, etc.).
At this point, the actual data processing can begin. Create procedures
that solely operate on the objects we created, making use of the built-in
methods these objects provide, and writing our own methods as necessary.
When all the procedures are complete for whatever we're trying to do, use
another utility routine to write the resulting data transformations back
to the relational database we started with.
Is this about right? If so, doing it this way, what real-world advantages
do we now have using the OO methodology? Is all this added overhead
really worth it? The best scenario I can imagine is that maybe, once
we've set everything up in an OO model, the procedures that actually
process that data will be a fraction of the amount of procedural code
required to simply process against the database directly. In other words,
is OOP really the better way to go in real-world, production business
applications, or is it mainly a nice academic exercise? thanks
-Fred
.
- References:
- OOP and databases in the real-world
- From: Fred Exley
- OOP and databases in the real-world
- Prev by Date: Re: Memory Leak in .NET 1.1
- Next by Date: endedit in formclosing
- Previous by thread: OOP and databases in the real-world
- Next by thread: Re: OOP and databases in the real-world
- Index(es):
Relevant Pages
|
