Does anyone see any problems inheriting from DataSet, DataTable & DataRow?

M

Mark Miller

I am building a data access layer and I want to encapsulate the data update
logic with the functionality of the DataSet, DataTable & DataRow classes. I
don't like typed datasets for two main reasons: control and maintenance ( We
have a small development team and I really don't like the idea of having to
rebuild the class each time I modify the table design ).

So my question is: If I inherit directly from DataSet, DataTable and
DataRow, from your own experience, what kind of problems am I likely to
encounter? Would it be better to simply wrap the object in my own custom
classes and implement the functionality I want or inherit the functionality
and add my own on top?

thanks in advance,
Mark
 
S

Sahil Malik

Mark,

You ask a fantastic question.

There is really no problem inheriting from DataSets or other such objects -
but be wary of what you are running into.

As of ADO.NET 1.1, DataSet serialization over remoting channels is less than
optimal, it is serialized as XML even though you might use BinaryFormatter.
This problem from what I hear is being addressed in ADO.NET 2.0, but hey -
who knows what happens when it finally comes out. There are proposed
solutions to this problem, but all of them are less than perfect (I speak
out of painful practical experience).

Secondly, Datatables are not serializable. That is again something that will
be fixed in ADO.NET 2.0, but until then ...

Thirdly, if you do end up using strongly typed datasets, you won't have to
change their structure everytime you change your table structure. Ideally
your application design should wrap the exact table structure within stored
procs, and essentially you should be able to change the tables, and mirror
that in stored procedures, and your app would really never know. (or never
should know for that matter). In a development team, you should segregate
excellent dba's fulfilling this role. (My opinion only).

And lastly, consider this .. say you have a customer that needs to be read
from the database.

You could -

a) Send back a plain dataset, holding customer info.
b) Send a strongly typed ds, holding customer info.
c) Send back a custom object - serializable/remotable - holding customer
info.

Now say, your customer has a restriction that Purchase Date > Date of
Birth.... how would you really implement this??

In the UI? In the business layer?? In both?? practically speaking the middle
layer person wouldn't trust the UI person and you would have the logic
doubled up in the business layer and UI, and finally the logic would get out
of sync .. and maintaining that will be a royal pain. Instead if you were to
go with option #c, you could implement this validation in your custom
object, and now create a class - representing intelligent data. Not only
that, when WinFX comes out, you could adapt your class to suit that schema
... ., therefore, I would - over custom datasets/datatables advise you to
implement your own objects, representing intelligent data.

Note - there is a thin boundary between reinventing the wheel, and doing
what is pragmatic. If you were implementing ASP.NET authetnication, you
coudl redo everything yourself that MS gives you .. and that wouldn't be
advisable. You could essentially write your own data adapter .. in a project
... but .. the general rule of thumb is ..

"Reinvent only what is specific to you". Your data is specific to you, and
in my humble opinion, you should represent it using your own
objects/schemas - looking into the future what WinFX has to offer of course.

- Sahil Malik
Independent Consultant
You can reach me thru my blog at -
http://www.dotnetjunkies.com/weblog/sahilmalik/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top