OO DB question

[Chris]

I had a OO model worked out which involved forms populating new instances of
a class and being stored in an ArrayList. I'm now moving this over to a DB
backend rather than a file - I've been wondering if I even need to create
objects now? Could I just work directly with the DB e.g. form data will pass
directly to db handled in click events, the listview of objects can be read
straight from db (no need to instantiate classes).
I guess I'm after opinions on what others would do in these circumstances.
Would it be ok to interact directly with the DB, or should I use the class
instances as interfaces to the DB through their properties? Would this mean
I'd just instantiate a class to pass data to and from DB and then dispose of
it? Or keep one instance of each class to act as an interface?

Any opinions would be appreciated,

Chris

Ps Merry Christmas

 

[Chris]

I had a OO model worked out which involved forms populating new instances
of a class and being stored in an ArrayList. I'm now moving this over to a
DB backend rather than a file - I've been wondering if I even need to
create objects now? Could I just work directly with the DB e.g. form data
will pass directly to db handled in click events, the listview of objects
can be read straight from db (no need to instantiate classes).
I guess I'm after opinions on what others would do in these circumstances.
Would it be ok to interact directly with the DB, or should I use the class
instances as interfaces to the DB through their properties? Would this
mean I'd just instantiate a class to pass data to and from DB and then
dispose of it? Or keep one instance of each class to act as an interface?

Any opinions would be appreciated,

Chris

Ps Merry Christmas

Just to clarify, when I say create objects, I originally had objects for
each form (a diary page) which stored all the text and options. This was
placed in an ArrayList and output to a file on saving.

Chris

 

[Joanna Carter [TeamB]]

"Chris" <[email protected]> a écrit dans le message de [email protected]...

| >I had a OO model worked out which involved forms populating new instances
| >of a class and being stored in an ArrayList. I'm now moving this over to
a
| >DB backend rather than a file - I've been wondering if I even need to
| >create objects now? Could I just work directly with the DB e.g. form data
| >will pass directly to db handled in click events, the listview of objects
| >can be read straight from db (no need to instantiate classes).
| > I guess I'm after opinions on what others would do in these
circumstances.
| > Would it be ok to interact directly with the DB, or should I use the
class
| > instances as interfaces to the DB through their properties? Would this
| > mean I'd just instantiate a class to pass data to and from DB and then
| > dispose of it? Or keep one instance of each class to act as an
interface?
| >
| > Any opinions would be appreciated,
| >
| > Chris
| >
| > Ps Merry Christmas
| >
|
| Just to clarify, when I say create objects, I originally had objects for
| each form (a diary page) which stored all the text and options. This was
| placed in an ArrayList and output to a file on saving.

Whether you are using a file or a database to store your objects, you will
still need to manage your object's lifetimes. At the moment I presume you
are loading all your objects from the file at the start of the application
and then saving them back at the end; this is similar to the Prevayler
approach.

We have designed an Object Persistence Framework. This allows us to write
code to store and retrieve objects, regardless of the ultimate storage
mechanism. Our framework is primarily concerned with using an SQL database
but the beauty of designing an OPF is that we could read objects in from a
text or XML file and then write them back out to an SQL database, or vice
versa.

Typical client code looks like :

{
Customer c = new Customer();
c.Name = "Joanna";
// set other properties

PersistenceBroker.StoreObject(c);

Criteria crit = new EqualsCriteria<Order>("Customer", c);

List<Order> orders = PersistenceBroker.RetrieveList<Order>(crit);
...

}

From the client side, there is nothing to say what is being used for
storage, but the Broker could well have more than one data storage
Connection and you would maintain a register that records which Connection
is responsibel for storing which types of objects.

Joanna

 

[Joanna Carter [TeamB]]

"Joanna Carter [TeamB]" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...

And I still didn't really answer your question.

There really isn't anything that allows you to retrieve objects directly
froma database, which is why I mentioned the OPF idea. A database is not
modelled on tha same paradigm as an object model; the database uses a
relational model which is subtly different from an object model.

e.g.

database :

OrderLine
- ID: integer
- OrderID: integer
- Quantity: integer
- ProductID: integer
- UnitPrice: float
- Total: float

Order
- ID: integer
- Ref: string
- Date: DateTime
- CustomerID: integer
- Total: float

object model :

OrderLine
- ID: integer
- Quantity: integer
- Product: Product
- UnitPrice: float
- Total: float

Order
- ID: integer
- Ref: string
- Date: DateTime
- Customer: Customer
- Lines: List<OrderLine>
- Total: float

Notice that in the relational model, the Order table has no knowledge of the
OrderLine table but the OrderLine table has to have a foreign key field to
link its records to a particular record in the Order Table; there may be
additional referential integrity constraints and things like cascade
deletion to ensure that when an Order is deleted, all its Lines are also
deleted.

Using an OO approach, we can dispense with the foreign key from the Line to
the Order as the Order already knows about its Lines; in fact, there really
is no need for the Line to know about the Order, as in the relational model.
Notice also that we do not use integer IDs to link object together, but
instead real references to real objects.

It is this "impedance mismatch" between the relational model and the object
model that is resolved in an OPF. A mapping hierarchy lets us specify the
relational foreign key field links without polluting the object model. In
fact all a relational database behind an OPF has to do is simple single
table selects, updates and deletes, most of the time, as all the integrity
between objects is taken care of in the business object layer.

Joanna

 

[David Veeneman]

It's really an architectural question. Is the project small enough to manage
without an object model? for simple apps, you can pass datasets back and
forth. Definitely the easiest way to go. But this approach won't work in
more complex apps--multiple forms and numerous capabilities lead to
duplication and brittleness--when I fix X, I break Y. An object model helps
organize the work and isolate the various parts of the system from each
other, while not impeding communication among them. So, the question
becomes, "How much infrastructure do I need in this particular app?" For a
simple app, an object model is overkill.

 

[Chris]

It's really an architectural question. Is the project small enough to
manage without an object model? for simple apps, you can pass datasets
back and forth. Definitely the easiest way to go. But this approach won't
work in more complex apps--multiple forms and numerous capabilities lead
to duplication and brittleness--when I fix X, I break Y. An object model
helps organize the work and isolate the various parts of the system from
each other, while not impeding communication among them. So, the question
becomes, "How much infrastructure do I need in this particular app?" For a
simple app, an object model is overkill.

The app itself has 1 main form with a listview. Three types of journal can
be generated, each journal is a separate form with 5-20+ items of user input
being saved to a respective class.
Instances of these objects are stored in a List<T>, and information from
them is stored in the listview. The listview can be double clicked to edit
selected items (buttons and menus create this functionality too), items can
also be deleted in this manner. The items in list view can be sorted on a
number of criteria (dates, word search, journal type) and a combo box allows
the display of specific item types only in the listView. Other data
structures store wordlists used to colour specific words found in a journal
text body.
All the data contained in the journals in processed in a variety of ways to
produce a number of statistics.

The above is the main functionality of the application. The application
should store hundreds/thousands of journal entries at a minimum.

I thought that holding so many objects (some with large bodies of data in a
rtf form) in memory would make the application a huge memory hog, and
interfacing with a DB could possibly draw off only the items needed e.g.
listview will search the DB and draw the information it needs only. Double
clicking an item will cause the rest of the selected journal to be drawn
from the database and used to populate a form for editing etc.

Chris

 

[Joanna Carter [TeamB]]

"David Veeneman" <[email protected]> a écrit dans le message de (e-mail address removed)...

| For a simple app, an object model is overkill.

In my experience, an object model is never overkill; simple apps just need
simple object models.

I have seen too many apps start out as "just a quick little app" using
controls hooked up directly to database tables. Soon, just like Topsie, it
growed and growed; until it was an absolute monster of convoluted event
driven code on forms.

My advice is : Keep it simple, but design classes before you even look at
how you are going to store instances of those classes. It really does work
out better, even for small apps; sometimes, you can even get away with
XML-type storage; then when you decide to change to a proper database, all
your business logic will remain untouched, the only thing to chaznge will be
the storage layer code.

Joanna

 

[Chris]

Hi Joanna,

Thankyou for the detailed reply. I'm still digesting what you've written,
so I'll reply with any questions soon .

Chris

 

[Joanna Carter [TeamB]]

"Chris" <[email protected]> a écrit dans le message de [email protected]...

| The app itself has 1 main form with a listview. Three types of journal can
| be generated, each journal is a separate form with 5-20+ items of user
input
| being saved to a respective class.
| Instances of these objects are stored in a List<T>, and information from
| them is stored in the listview. The listview can be double clicked to edit
| selected items (buttons and menus create this functionality too), items
can
| also be deleted in this manner. The items in list view can be sorted on a
| number of criteria (dates, word search, journal type) and a combo box
allows
| the display of specific item types only in the listView. Other data
| structures store wordlists used to colour specific words found in a
journal
| text body.
| All the data contained in the journals in processed in a variety of ways
to
| produce a number of statistics.
|
| The above is the main functionality of the application. The application
| should store hundreds/thousands of journal entries at a minimum.
|
| I thought that holding so many objects (some with large bodies of data in
a
| rtf form) in memory would make the application a huge memory hog, and
| interfacing with a DB could possibly draw off only the items needed e.g.
| listview will search the DB and draw the information it needs only. Double
| clicking an item will cause the rest of the selected journal to be drawn
| from the database and used to populate a form for editing etc.

You really must separate the areas of displaying, managing and storing
objects

Ideally, large quantities of objects should be *stored* in a database.

How the objects are *managed* depends on quantities and other intangibles.
If you want to manage large quantities, then you would consider building a
broker which will page the objects into an in-memory list as required

*Displaying* the objects requires that your UI components will "ask" the
list for items, either on a one by one basis or a page at a time.

If you build your list class correctly, then it can surface events which can
be handled by a broker. The idea being that when the list is asked for, say,
item 45, the GetItem method would check to see if that item had already been
retrieved and, if not, would fire the ItemRequired event passing the index
required; the broker would note the index and check how many objects would
have to be retrieved to cover that index number. IT is always best to page
objects to save time, so 45 on a 10 page strategy would mean loading at
least four pages of objects.

You could also remove unused objects when they are no longer required, but
this will depend on the speed requirements of the program as to whether this
is reasonable or not.

Sorting objects that have been stored in a database and which are being
drawn into a list is usually best done by issuing SQL against the database
with a sort clause. Sorting the list means calling a Sort method on the list
class which is used to fire an event which is captured by the broker, which
will reload the list with objects sorted in the required order.

As to populating "large" objects; you are best working with partially loaded
objects for the purposes of browsing in a list, only loading all the
properties when a full object is selected for editing.

Looking at your message, it would seem like you are moving in this direction
anyway

Joanna