Reflection or Strongly Typed data sets

I've been using reflection for some time now to easily translate database schema's to c# objects. Basically my reflection updates/Inserts/ deletes itself from a database. I also have an init function that uses a stored procedure to get it's own data from the database.

The beauty of this thing is that when I add a column to a table all I have to do is update the stored procedures that I'm using and add a property in the object. I don't have to manually create and fill out more properties.

I'm wondering if I should move to strongly typed data sets or not? I've tried to read up on it but I'm still a little unsure as to how they work and the pros and cons of em.

Please some information on this subject would be most helpful.

I'm looking for a solution that is flexible enough to handle changes to the underlying schema and is easy to maintain.
Who is Participating?
gregoryyoungConnect With a Mentor Commented:

have you considerred looking at an object persistance layer ? take a look at or both do VERY well at this task ... it would actually only be adding a property and an attribute in your class ...

as for typed datasets, I personally don't like them ... one of the main problems I have been seeing in MS lately is a division between the object persistance people and the typed dataset people. Due to this choosing which way to go is becoming difficult as some things offer support for one and not the other.

One advantage of moving towards a persistance layer is that yukon essentially contains a persistance layer in the database which will make moving your code to it a bit easier with a persistance layer than with typed datasets.
TheAvengerConnect With a Mentor Commented:
I think the answer to the quesion lays in the needs you have. If you want to update objects that have a structure you don't know or which changes often, I would not go for a typed dataset. However if you objects have a relatively stable structure and you don't have to work with any kind of objects, then using a typed dataset will make your development life much easier, will save you some mistakes, etc.
jayrodAuthor Commented:
I guess often is a word that has to be defined :P  I would say that the schema can change often enough to cause annoying problems.

I looked into and looks like a great Idea.. I spent some time trying to use it but haven't gotten it to work just yet.

Thank you both.
TheAvenger: I know I am stepping into a religious war here ... but are true object persistance layers not more flexible than types datasets ?
gregoryyoung: Unfortunately I have no info about object persistance layers... I can only guess what it is by the name. And would expect the answer to your question to be: yes, they are. But look at my post: it said that typed datasets would be better only if the data structure is well fixed, does not change, is known at design time, etc. In this case the complexity of an additional layer just to have the data in a more flexible (which is not needed in such case) format....

So, if you are working with a fixed database, I would suggest typed datasets - easy to implement, designer supported, go for it and make it fast and clean. If the case is not such one, other options have to be considered and then I suppose your answer will be just OK
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.