E
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.
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.