Inheriting dataset

  • Thread starter Thread starter Johan Karlsson
  • Start date Start date
J

Johan Karlsson

Hi!

I have a typed dataset generated from an xsd file. If I want to add more
functionallity to this, is it a bad idea to inherit from the autogenerated
class file and use that one in all dataset operations?

In that way I can add methods to perform the operations I need without the
risk of the code being overwritten by the generation tool.

I havn't seen this around so much.
Is this a good or bad idea?

Thanks
/Johan
 
Hello!

Thanks for the response, but that was not really the answer to my question.
The bottom line was IF it was a good idea to inherit from a typed dataset or
not. I've been using this for a couple of days in my design and I see no
downsides so far.

/Johan
 
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


One way would be to create typed dataset code by yourself.
You might take a look at Code Smith at
http://www.ericjsmith.net/codesmith/.
I think it has a strong typed dataset template which you can freely
modify
to your needs.
 
Thank you!

That information is really useful!
Keep up the good work!

/Johan

scorpion53061 said:
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


One way would be to create typed dataset code by yourself.
You might take a look at Code Smith at
http://www.ericjsmith.net/codesmith/.
I think it has a strong typed dataset template which you can freely
modify
to your needs.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development

Johan Karlsson said:
Hello!

Thanks for the response, but that was not really the answer to my
question.
The bottom line was IF it was a good idea to inherit from a typed dataset
or
not. I've been using this for a couple of days in my design and I see no
downsides so far.

/Johan
Click to expand...
Click to expand...
 
I downloaded the CodeSmith that generates a Strongly Typed Dataset, but
unfortunately, You can generate a dataset of 1 table... You can't generate a
DS with few tables and relations between them.... So what is the advantage??

scorpion53061 said:
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


One way would be to create typed dataset code by yourself.
You might take a look at Code Smith at
http://www.ericjsmith.net/codesmith/.
I think it has a strong typed dataset template which you can freely
modify
to your needs.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development

Johan Karlsson said:
Hello!

Thanks for the response, but that was not really the answer to my
question.
The bottom line was IF it was a good idea to inherit from a typed dataset
or
not. I've been using this for a couple of days in my design and I see no
downsides so far.

/Johan
Click to expand...
Click to expand...
 
Back
Top