Object orientation and relational databases

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Emmanuel Tzevelekakis - 21 Feb 2004 17:11 GMT

Hi there

I wonder where can I find documentation/information on how to implement
classes that relate to database tables.

Especially I would like to answer the following (design) questions:

1. Suppose we have a Client class and a ClientGroup class that correspond to
Clients table and ClientGroups table. How will the Client class be
implemented ?

a) like the database table (with to separate classes):
+---------------+ +-------------+

| Client | | ClientGroup |

+---------------+ +-------------+

| Id | | Id |
| Description | | Description |
| ClientGroupId | +--------------+

+--------------+

b) In a more attractive (object oriented) manner:

+----------------+ +--------------+

| Client | +---> ClientGroup |

+----------------+ | +--------------+

+---------------+
(ClientGroup attribute in Client class is an object of type ClientGroup that
has an Id and a description.)

If (b) is the right way to go, how will the Client object be filled from the
database ?

2. Will the FillObject method load the corresponding ClientGroup object
(Will it fill its Description attribute) ? If yes, what would happen if the
object had many references to other objects or worse to other object
collections ?

3. When I want to work with many objects that are a result of a database
query will I use DataTables or object collections ?

4. Reading articles here and there, we are often encouraged to separate
Database tier from Business tier and Presentation tier. We are supposed to
hide database implementation, from presentation tier. So if we want to get
an object collection of clients we have to implement a method like
ClientCollection.LoadClients() that will be called from the presentation tie
r in order to fill a data grid of all the available clients. The problem is
that in real world applications the things are not so straight forward.
There are times that we want to load all the clients that their Surname or
Company descriptions starts from a specific letter, clients that are from a
specific country, clients with a specific zip code, or worse, clients that
have played their bills or with a debit rest greater than 10000 etc.

How will all this logic be hidden from the presentation tier ? Will we
implement methods like ClientCollection.LoadClientsByName(string
searchDescription), ClientCollection.LoadClientsByCountry(string
searchCountry), etc ? If we use methods like
ClientCollection.LoadClients(string sqlStatement) it is obvious that we
break/violate the 3-tier architecture, since the presentation tier knows the
implementation of database tables.

I have more questions, but these questions are relative to the answers of
the above questions.

It is obvious that it is not clear to me how the object oriented paradigm
interacts with the Database table/record paradigm.

Do you have any suggestions or links/references ?

Thank you

Emmanuel

Reply to this Message

Paul N - 23 Feb 2004 17:11 GMT

Hi Emmanuel,

Reading your (long) email, I can't help but suspect you
are looking at your problem from the wrong direction. I
build objects and object collectioons (very variable) from
a database all the time. I will try and answer your
various questions below - but it really isn't that hard
once you start approaching it from the right angle.

Paul.

>I wonder where can I find documentation/information on how to implement
>classes that relate to database tables.

Many books show this - I use ASP.NET Unleashed, but there
are many many books showing how to use ADO to do this.

>Especially I would like to answer the following (design) questions:
>
[quoted text clipped - 22 lines]
>(ClientGroup attribute in Client class is an object of type ClientGroup that
>has an Id and a description.)

(b) is the way i would do it.

>If (b) is the right way to go, how will the Client object be filled from the
>database ?

easy. Simply create your SQL, connection and dataset
objects as required. Next, carry out the SQL to fill a
table in the dataset with rows corresponding to clients.
For each row/set of rows corresponding to a single client,
create and fill a new client object. Add this client
object to a collection of client objects. once you are
done, you can go through this clients collection, placing
clients into clientGroup objects. (one clinets collection
per client group object). I have found a HUGE help in
making this process easy is getting the SQL right at the
very start.

>2. Will the FillObject method load the corresponding ClientGroup object
>(Will it fill its Description attribute) ? If yes, what would happen if the
>object had many references to other objects or worse to other object
>collections ?

This is entirely dependent on the way you design your
system. If your client group is supposed to have only one
description, equivalent to the description of the clients
in that group - but these clients themselves have more
than one description, then should they be in that group?
This is a business question, and one that you should have
answered before you go anywhere near a computer.

>3. When I want to work with many objects that are a result of a database
>query will I use DataTables or object collections ?

I think I have kind of answered this above - but I create
DataTables within DataSets, and from the data in there,
create the collections of objects.

>4. Reading articles here and there, we are often encouraged to separate
>Database tier from Business tier and Presentation tier. We are supposed to
[quoted text clipped - 15 lines]
>break/violate the 3-tier architecture, since the presentation tier knows the
>implementation of database tables.

I implement my "middle tier" as a DBAccess object. This is
where the queries are carried out, DB connections made
etc. I actually create the SQL in the code behind the web
pages - but that isn't necessary. In earlier applications,
I created the SQL in the DBAccess object - but this made
maintenance slightly more difficult, as when changes
needed made to the web page, these changes inevitably
affect the SQL you need, and so simply moving between the
page code and the DBAccess class cuased difficulty. By
placing the SQL creation code in the code behind,
everything is right there, the SQL is created where it is
needed and complete SQL handed off to the DBAccess object.
Where I can, I place as much SQL in stored
procedures/functions/triggers on the database itself, some
regular non-iteractive SQL in the DBAccess object, but the
user interaction queries are all built in the code behind
the pages.

>I have more questions, but these questions are relative to the answers of
>the above questions.
>
>It is obvious that it is not clear to me how the object oriented paradigm
>interacts with the Database table/record paradigm.

These paradigms are kind of confusing - you need to leap
the "Object Orientation Gap". Once you do, it will all
become astoundingly straightforward. Basically, create
objects and object collections from relationally stored
data.

Hope this helps,

Paul.

Reply to this Message

Object orientation and relational databases

Free Magazines