DataSet's Vs Object Model

[MattC]

Hi,

I have question that I'd like to throw up for a discussion as I cant seem to
figure out the answer myself.

I have implemented an object model in an ASP.NET application. Classes use
inheritance, aggregation and all the other OO means of data encapsulation.
The persistant store for the data is a database, so 3rd Normal form etc...

Here's where thing get interesting (well, kinda). I have create a series of
collection classes that derive from ArrayList and allow objects within my
objectmodel to be stored in their respective collection class. For example
a Department class with have a related DepartmentCollection class for
storage of many objects.

These collections can then be bound to a datagrid and using the bound column
template I can pick any data from the object model, so I can display in the
grid the salary of the manager of each department in the collection.

This is great and very flexible. However, if I wish to use the features
provided by ADO.NET then having an object model is not so useful. For
example a user table exists of the username, securityprofileid and
activeaccountflag, departmentID. Pulling out the user details into my user
class would then fill all the details relating to the class, so the
Department ID is used to get the aggregate Department object and the same
with the SecurityProfile object. With a DataTable I would only have that
data which came from the table, i.e, the four fields with the object model
much more data.

So when I come to use sorting or filtering which is provided by the
DataTable class I can only sort and filter on those fields available. If I
want the same data as in my previous example of the manager's salary, I
would need to create a DataSet that contained then data I wanted to display
in that grid. Somewhat bypassing the object model.

I would love to read any thoughts people have or suggestions, I am by no
means an expert onteh subject so it is entirely possible that I have missed
something very simple.

TIA

MattC

 

[Kris Desmadryl]

I'm struggling with the same problem, uptill now I decided to use only
datasets and no object model.

I used to add the logic of filling the dataset in the dataset. I extended a
strong typed dataset and added some fill methods etc. But these strong typed
datasets contains some inner classes (datarow, datatable etc). So it is
impossible to add some extra methods on the table. A better approach I think
is to use the datasets only as a bag for data. Filling of the datasets
happens in the business layer (BUL).
You for example a class Person in the Bull with methods GetAllPersons,
GetPersonByName(...., DeletePerson(ID as integer), UpdatePersons(ds as
dataset)

If you want to use a object model the method GetAllPerson of the return your
proper personcollection (instead of a dataset), but this means that you have
to convert the dataset (you get from your DAL) to the personcollection. And
ofcourse this personcollection must be bindable to a datagrid. All this
seems to me a lot of work. But an Object model is cleaner. So I'm struggling
too.


Kris

 

[David Jessee]

First, on the fact of sorting, look at the IComparer Interface. I know
that's not what the message was really about, but its a good piece of trivia


Making a migration from a data-centric approach to development to an
object-centric approach is difficult. Especially when you're talking about
object persistence in a relational database. I've had to do all sorts of
things to facilitate the process (e.g. having constructors that take an
IDataReader, Having collections implement a "ParentId" Method).

I can tell you the things that have helped me a lot, though.
First, only look at the persistence model after you have flushed out your
object model. Create Factory classes that manage Instatiation and
Repository Classes that save Instances and perform lookups. But ONLY look
at the external interfaces for these ... don't think about what the tables
will look like because sometimes after you have a good understanding of your
model, certian aspects of your model will behave best if they're (dare I say
it) de-normalized. Sometimes the relational view of your persistence will
not have a 1-to-1 correlation with your classes (there's a belief that if
there's a person class, there should also be a person table).

Once your model has been flushed out, and you understand its behavior, you
can start looking at a relational model for it. note, you may have to make
some adjustments in your model to accomidate for the relational integration.

There are a number of tools out there that accomplish this task.
Additionally, there are some persistence frameworks in development on some
public sites (do a search for "persistence" on gotdotnet.com). But
ultimately it comes down to you finding the best way for your model to be
persisted. For instance, I have one project in the works with a rather
complex object has to be saved to the database. Since this complex
hierarchy (7 type definitions and 4 collection types) will not need to be
queried, I'm serializing the entire instance to a memory stream, base64
encoding the result and sticking it into a text field.

One book I read that gave me a lot of insight into this process was
"Domain-Driven Design: Tackling Complexity in the Heart of Software" (Rick
Evans). You'd definately get something out of it.

 

[MattC]

Thanks guys,

Yeah so far I have been implementing an object model driven design where
possible using Collection classes specific for the obejcts and yeah those
sealed IComparer classes are cool.

On that Topic is there an interface that will allow yoo to create a filter
for a collection.

Failing that, I guess I will have to implement filtering support in the base
collection class and try to make it overidable, a la Sort.

MattC

 

[MattC]

Check out this blog, kinda solves my problem

http://dotnetjunkies.com/WebLog/bsblog/archive/2004/09/02/24116.aspx

 

[David Jessee]

If you have a class that implements IComparer that has properties you can
set, or a constructor:

e.g. new MyCoparer(new object() {"FirstName","ASC","LastName","DESC"})

you could make the implementation of the class use reflection to determine
which properties to compare (FirstName, LastName) and how to order them
(ASC, DESC)

 

[MattC]

Exactly what I'm working on. A FilterComparer style. I'll post what I got
when I get something working, its abit crude but will do the job for now.

MattC