Relational database & OO

My question relates to good design when it comes to creating an OO
application that uses a relational database to store most of its data,
how do people go about designing and storing the data once it has been
retrieved from the database? Do you keep it as records, or when you get
the data, do you create collections of objects which represent the data
which you have obtained from your database?

I am wanting to create an application that is for time management and I
want most of the data to be on my webservers database, but in creating
my OO 'client' I really want to create a good design.

Anthony

ajspowart{} wrote:

> My question relates to good design when it comes to creating an OO
> application that uses a relational database to store most of its data,
> how do people go about designing and storing the data once it has been
> retrieved from the database? Do you keep it as records, or when you
> get the data, do you create collections of objects which represent
> the data which you have obtained from your database?
>
> I am wanting to create an application that is for time management and
> I want most of the data to be on my webservers database, but in
> creating my OO 'client' I really want to create a good design.

It's IMHO always a good idea to start with a design for your abstract
datamodel. This is a level above E/R, so it can have inheritance etc.
For the technique, please check http://www.orm.net (Object Role
Modelling, formely known as NIAM)

This gives you a good idea which entities are identifyable within your
system, their attributes and their relations with other entities. Once
you've modelled this out, you can go in several directions: you can
pick this model and turn it into a domain model (thus a class model)and
simply get an o/r mapper of your liking and store the entities into a
physical datamodel matching your domain model.

You can also pick it up and create a physical data model in a database
with it and use it as well for your entity classes, which are then
consumed by your application logic.

Please read my essay about this here:
http://weblogs.asp.net/fbouma/archiv...0_-The-Databas
e-Model-is-the-Domain-Model.aspx

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

ajspowart{} wrote:
> My question relates to good design when it comes to creating an OO
> application that uses a relational database to store most of its data,
> how do people go about designing and storing the data once it has been
> retrieved from the database? Do you keep it as records, or when you get
> the data, do you create collections of objects which represent the data
> which you have obtained from your database?
>
> I am wanting to create an application that is for time management and I
> want most of the data to be on my webservers database, but in creating
> my OO 'client' I really want to create a good design.
>
> Anthony

This is an age-old quesition. OO and relational tend to have different
philosophical tilts such that there is no easy or universal way to meld
them.

-T-
oop.ismad.com

Responding to Ajspowart...

> My question relates to good design when it comes to creating an OO
> application that uses a relational database to store most of its data,
> how do people go about designing and storing the data once it has been
> retrieved from the database? Do you keep it as records, or when you get
> the data, do you create collections of objects which represent the data
> which you have obtained from your database?
>
> I am wanting to create an application that is for time management and I
> want most of the data to be on my webservers database, but in creating
> my OO 'client' I really want to create a good design.

I assume the time management application does something complex rather
than simply acting as a pipeline between RDb and UI (i.e., CRUD/USER
processing). If not, you can stop reading.

Solving a time management problem is a quite different subject matter
than persisting the relevant data. Solve the time management problem in
you application first. Then, when you know what object attributes need
to be persisted, define a suitable Data Model for the database. The RDB
Data Model and the solution's Class Model will typically be different
for non-CRUD/USER applications because they need to be optimized
differently.

Finally, provide a subsystem for the application that maps between the
two views. The interface to the DB Access subsystem is defined by the
time management solution's need to obtain and store data to initialize
and save objects. The DB Access subsystem then maps those requests into
SQL queries or whatever that are appropriate for the Data Model.

Typically, on the solution side one will have factory objects to
instantiate the solution's objects. Those factory objects will request
the appropriate data from the DB Access to do the instantiation and
initialization. Conversely, when it is time to save attributes from the
solution objects, some object extracts the relevant attribute values
sends them off to the DB Access subsystem to be stored.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

ajspowart{} wrote:
> when it comes to creating an OO application that uses a relational
> database to store most of its data, how do people go about designing
> and storing the data once it has been retrieved from the database?
> Do you keep it as records, or when you get the data, do you create
> collections of objects which represent the data which you have
> obtained from your database?

Martin Fowler's book "Patterns of Enterprise Application Architecture"
covers this territory. It would be a good starting point.

Doug Pardee wrote:
> ajspowart{} wrote:
> > when it comes to creating an OO application that uses a relational
> > database to store most of its data, how do people go about designing
> > and storing the data once it has been retrieved from the database?
> > Do you keep it as records, or when you get the data, do you create
> > collections of objects which represent the data which you have
> > obtained from your database?
>
> Martin Fowler's book "Patterns of Enterprise Application Architecture"
> covers this territory. It would be a good starting point.

Or yeah. A tiny time management application certainly needs to be
hammered with "Enterprise strength" approach.

Keep it simple. Write a minimal amount of code that transfers the
information from the database to the GUI. Don't create classes unless
you really forced to. Ignore all the temptations to design for "future
extensibilty" -- just admit you don't have crystall ball to know the
future. Embed all the SQL in java code, because it is the most simple,
readable and easily maintainable way to program database application.

On Thu, 02 Nov 2006 17:21:51 GMT, "H. S. Lahman"
<h.lahman{}verizon.net> wrote:

>Responding to Ajspowart...
>
>> My question relates to good design when it comes to creating an OO
>> application that uses a relational database to store most of its data,
>> how do people go about designing and storing the data once it has been
>> retrieved from the database? Do you keep it as records, or when you get
>> the data, do you create collections of objects which represent the data
>> which you have obtained from your database?
>>
>> I am wanting to create an application that is for time management and I
>> want most of the data to be on my webservers database, but in creating
>> my OO 'client' I really want to create a good design.
>
>I assume the time management application does something complex rather
>than simply acting as a pipeline between RDb and UI (i.e., CRUD/USER
>processing). If not, you can stop reading.
>
>Solving a time management problem is a quite different subject matter
>than persisting the relevant data. Solve the time management problem in
>you application first. Then, when you know what object attributes need
>to be persisted, define a suitable Data Model for the database. The RDB
>Data Model and the solution's Class Model will typically be different
>for non-CRUD/USER applications because they need to be optimized
>differently.

I agree with the solution, but I really think one is talking about a
Persistant Storage Engine (PSE) rather than perhaps an OO database. A
PSE can often be implemented using an object schema or RDB model.

The difference between what I think should be a true OO database and a
PSE is that to me the former has no separation of state between what
is executing and what is stored. There shouldnt be any concept of
storage or transience or separation of application and data - just
"IS-ness of the whole" as I call it.

I made the comment in another thread that OO does not have a concept
of transience - its a programmers abstraction and probably the cause
of many RDB vs OO DB debates..

Once a developer starts talking about persistance and those related
terms they are talking about separation of data and code and to be
honest, they may as well use an RDB.

I've always felt that a good way to understand OO DB concepts is to do
some CORBA development. One calls an interface on an object in ones
client application, the fact that the behind the scenes execution is
done in a different country on the other side of the world and may or
may not invovle a cluster of database servers (object or relational)
is completely transparent to the client developer. To the client -
things just happen.

Andy

> Once a developer starts talking about persistance and those related
> terms they are talking about separation of data and code and to be
> honest, they may as well use an RDB.

If the developer uses a RDB, he will not have to care about the
persistance aspect at all. Persistence is a feature at the bottom of
the RDB stack. The user of a RDB doesn't know of the data he is working
with is cached or actually read from disk. Even if persistence is not
needed, one would probably need a RDB for all other features.

> I've always felt that a good way to understand OO DB concepts is to do
> some CORBA development. One calls an interface on an object in ones
> client application, the fact that the behind the scenes execution is
> done in a different country on the other side of the world and may or
> may not invovle a cluster of database servers (object or relational)
> is completely transparent to the client developer. To the client -
> things just happen.

The same could be said about SQL and ODBC/JDBC/ADO. The fact that
behind the scenes execution is done using a all-in-memory lightweight
database or a monster database like DB2 is completely transparent to
the client developer.

Fredrik Bertilsson

frebe73{} wrote:
> > Once a developer starts talking about persistance and those related
> > terms they are talking about separation of data and code and to be
> > honest, they may as well use an RDB.
>
> If the developer uses a RDB, he will not have to care about the
> persistance aspect at all. Persistence is a feature at the bottom of
> the RDB stack. The user of a RDB doesn't know of the data he is working
> with is cached or actually read from disk. Even if persistence is not
> needed, one would probably need a RDB for all other features.

An RDBMS does a great job of handling all of that mess, and more (ACID
transactions are the real kicker - thank goodness we don't have to
re-implement /that/ wheel) for _data_, but the OO programmer who wants
her _objects_ (data married to related behavior) to 'persist' across
multiple user sessions/program executions/phases of the moon is working
at a somewhat higher level. The problem then becomes one of
instantiating relationships - if an object is persistent, it needs to
be loaded from the storage mechanism at some point. Who does that? Who
loads other persistent objects associated with the first? Where are the
transaction boundaries? If these persistence-related concerns are
sprinkled about your business logic, your code will be much harder to
adapt to changing requirements.

Quoting AndyW:
>> The difference between what I think should be a true OO database and a
>> PSE is that to me the former has no separation of state between what
>> is executing and what is stored. There shouldnt be any concept of
>> storage or transience or separation of application and data - just
>> "IS-ness of the whole" as I call it.
>>
>> I made the comment in another thread that OO does not have a concept
>> of transience - its a programmers abstraction and probably the cause
>> of many RDB vs OO DB debates..

I agree - unfortunately, for those of us still doing ORM, the
frameworks available still require you to do a lot of grunt work to
maintain your objects. Hibernate, for example, is designed for fairly
short 'sessions' of work which will be persisted. When a Session has
closed, the objects loaded in that session are considered 'detached,'
and changes to their internal state will not be persisted unless they
are merge()ed with another Session. Worse, accessing a lazily-loaded
collection on a detached object throws an exception, because the
Session is closed and the collection proxy has no way of obtaining its
objects.

I've been lately relying on a combination of AOP and transitive
persistence to try and seperate these sorts of persistence concerns out
from the rest of my code entirely. Spring has some useful AOP helper
classes which allow for declarative transaction demarcation, which is
one piece of the puzzle. I've written some of my own AOP wrappers for
re-attaching detached objects to new sessions automagically. Making use
of Hibernate's transitive persistence mechanism to transparently
cascade re-attachments when necessary completes the picture.

Using these techniques, the high-level application and business logic
for our current app has stayed *very* clean and simple - significant
program changes have been comparatively easy because there is no
persistence-related code which needs to change when the business logic
needs to change.

What's been /really/ interesting has been trying to allow for
relationships between objects which are persisted to entirely different
data stores =) I haven't pinned down a good way to do this with
Hibernate just yet (assuming one can be found).

> but the OO programmer who wants
> her _objects_ (data married to related behavior) to 'persist' across
> multiple user sessions/program executions/phases of the moon is working
> at a somewhat higher level.

If the OO programmer only needs persistence, and RDBMS is a huge
overkill. A much simpler tool would do.

> The problem then becomes one of
> instantiating relationships - if an object is persistent, it needs to
> be loaded from the storage mechanism at some point. Who does that? Who
> loads other persistent objects associated with the first? Where are the
> transaction boundaries?

A RDBMS is not a storage mechanism. A storage mechnism is much simpler.
Transactions and persistence are two orthogonal features.

> If these persistence-related concerns are
> sprinkled about your business logic, your code will be much harder to
> adapt to changing requirements.

If you use SQL in your application, your application will contain no
persistence related logic at all.

Fredrik Bertilsson