Using Relational-Databases in Object Oriented design

[Eric Nilsson via .NET 247]

I need a good design (pattern?) for working with persistantobjects.

This is what has been bothering me, I'm on 3'rd year inuniversity learning computer science, and I am now working on amedium-sized project involving persistant objects resting in arelational database. I'm developing it in .Net using C#. But i'mhaving problems persuing true object orientated design in thesekind of programs.

Basicly, what I used to do all the time, was to make my own SQLclass which would function as a wrapper for the ADO layer, Suchas DoCommand(string query), which I would use in my applicationclasses to work with Sql.

The problem with this is that now the Application Classes are theones creating Sql statements for the database and directlycommunicating with it, which goas against many OO principles.

So what I think of doing (and my teacher suggested me to do), isto have a Sql class handle all the database transaction, andequip it with methods that recieve application models, fillsthem up (or saves them) etc.

Ok, that would fix some areas, but brings its own issues. F.ex.this class would get pretty sizey, handling all thosetransactions (ofcourse I could make a Sql class tree, delegatingit a bit, or (as I saw alsewhere) make Data-classes for everypersistant class that handles it).

But the biggest issue with it, and this is my current problem, isthat it would require all members in the class to haveread/write access (so they can't be read-only). This, ofcoursegoes against all sorts of OO principles, and in my cases, I needalot of my members (which still are persistent) to be read-only(it's a .dll).

So... what can I do? What would be the best way to solve thisissues with OO-principles in mind?

~ Eric Nilsson ~

ps. I tried searching the web without much success (all keywordsare highly common), but if someone knows a article about this,then please link me.

-----------------------
Posted by a user from .NET 247 (http://www.dotnet247.com/)

<Id>f5R03hPlcUuhnDsxUmjT2Q==</Id>

[Cor Ligthert]

Eric,

The first thing I would look for is ADONET. That is built with OOP in mind.

The newsgroup for that is
Adonet
news://msnews.microsoft.com/microsof...amework.adonet

Web interface:
http://communities2.microsoft.com/co...amework.adonet

I hope this helps,

Cor

[Chris Clark]

I have encountered just the problem I think you are dealing with here. I used
the ADO.NET dataset in the first release of a fiarly large enterprise
application. The choice was made more on a whim and a hope of meeting the
deadline rather than than as the result of a good brainstorming session. I
have found that creating my own wrapper classes for data (Order, Patient,
Physician, Encounter, OrderItem) is much better than a strongly typed
dataset. Simply put, all named objects expose much more functionality than a
VS-generated strongly typed dataset can provide. My final solution was to
create a custom wrapper for a typed dataset. And yes, there is alot of code
dealing with database access including concurrency.

"Cor Ligthert" wrote:

Eric,

The first thing I would look for is ADONET. That is built with OOP in mind.

The newsgroup for that is
Adonet
news://msnews.microsoft.com/microsof...amework.adonet

Web interface:
http://communities2.microsoft.com/co...amework.adonet

I hope this helps,

Cor