Datasets and business objects

[Frédéric Mayot]

Hi,

In my web application, I need object-relational mapping. I would have liked
to take advantage of the datasets while keeping encapsulation of the data. I
thought about having a protected dataset attribute in my business objects
classes and creating properties to access each column. Thus, I will be able
to update and insert data without writing SQL code.

Do you see drawbacks to this approach ?

What if I decided to keep some business objects in session (the web
application won't be very stressed) ?

Thanks.

Fred

 

[Paul Mason]

Hi Fred,

Simple answer to this is not to re-invent the wheel. I've been revealing
datasets to the outside world for quite a while now without any problems.
If you've analysed you're system using UML (if not learn it quick...makes
life a whole load easier), you'll begin to appreciate that objects can be
both data bound and non-data bound at the same time.

For instance you may have an object called clsPerson. This has attributes
like Surname, Forename, Gender , date of birth etc etc. You also want it to
insert and update the equivalent record in the table tbPerson, so you have a
method called Save that either calls Insert or Update and uses the data in
the attributes to do this. A typical data bound object would have a routine
called GetPerson(PersonID), which picks up the data from the tbPerson and
populates the attributes for when you want to view data.

In a typical system you may have a screen that shows a list of people, from
which you select one person which you wish to show/edit the details. The
above object services the latter part of this, but doesn't obviously help
with the list....wrong! The class clsPerson, can just as easily have a
method called GetPersonList which returns a dataset. This method doesn't
care if the attributes have any values in...this is classic non-data bound
object (sometimes called helper objects). Whats more it all uses the same
connection structure as I've described before so that you an just use the
one connection in all of your objects.

If you're not using UML, then you're not going to be able to get the best
out of any OOP system.

I would avoid getting too many objects in memory. For a start you're at the
mercy of timeouts and other such nonsense. If you're application isn't that
demanding, don't worry about making too many requests to the database. The
key here is the connection objects (see previous answer).

Cheers...P

 

[Eliyahu Goldin]

Fred,

Looks like you are on the right track. I am doing something similar in my
applications. Note, that if you are using typed datasets, Visual Studio
creates a lot of useful classes for you and all properties are already
there, you don't need to write your own code for that.

I don't think keeping datasets in session is a good idea. That's what
database server is for.

Eliyahu

 

[Joe Fallon]

You may want to check out Rocky Lhotka's CSLA framework for Business
objects.
The book is an EXCELLENT read.

I just completed a large ASP.Net project using CSLA. Works great.

http://www.lhotka.net/ArticleIndex.aspx?area=CSLA .NET