"Fred Exley" <fe*******@msn.com> a écrit dans le message de news:
12*************@corp.supernews.com...
|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.
The most important thing to remember when designing good OO systems is, not
to take an existing database design and try to make classes taht wrap the
data tables.
This will give you a very poor model compared with one that starts with
classes and then mapped to tables.
| 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.
Take a look at the concept of OPF (Object Persistence Frameworks) this is
designed to separate out anything to do with databases from the business
classes or UI.
| 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.).
The normal way of designing classes is to model the real world as closely as
possible, taking care not to use relational modelling as you would with
databases.
In the case of a "composite" class like a Sales Order with Order Lines, you
would simply design the following classes similar to this :
public class Order
{
public class Line
{
// private fields
public int Quantity { ... }
public Product Product { ... }
public decimal Total { ... }
}
public DateTime Date { ... }
public Customer { ... }
public ReadOnlyList<Line> Lines { ... }
public Line AddLine() { ... }
public void RemoveLine(Line line) { ... }
}
This arrangement assumes you are using .NET 2.0 where you can use nested
types to indicate that Line is only available within the context of Order.
The list of lines uses a generic list class that ensures that lines cannot
be added to or removed from the list except by using the methods provided in
the Order class; this further reinforces the idea that Lines cannot exist on
their own apart from the Order; their lives are governed by the life of the
Order.
| 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.
A good OPF should be able to translate objects into SQL statements and also
to construct SQL to retrieve objects as and when required, but any and all
processing should be completely inaccessible from outside of the OPF.
| 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 real world advantages of using an OPF is to separate storage of objects
from the business logic af any applications that should want to store
objects from how those objects are stored.
After a good OPF is in place, then the advantages of well-designed classes
is that they allow data and the code that relates to that data to reside in
close union insode a single class; the term "responsibility driven design"
indicates that classes should be designed to be responsible for their own
well-being, nothing more nothing less.
In this regard, it is important to realise that there will be more classes
than those that map to tables; you will find classes that have no need to be
persisted but simply exist to connect and facilitate within the application
without necessarily being persistable.
| 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
There are many industrial strength applications out here that are designed
using OO - the whole .NET framework is designed using OO.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
