Groups | Blog | Home
all groups > dotnet ado.net > may 2007 >

dotnet ado.net : What is the max number of tables advised to use with typed datasets?


Brooke
5/5/2007 9:28:23 AM
I am helping develop a SQL Server 2005 application with a C# front-end.
Originally I was using untyped datasets and stored procedures and it worked
fine. Now I have been told to used typed datasets and table adapters. Is
it a good idea to use typed datasets on a database with about 25 tables?

Typed datasets are much easier in some aspects, but I am finding it
difficult to change certain things without the application blowing up, and
it takes a lot of effort to maintain the typed datasets if the underlying
SQL Server database structure changes (new fields, renamed fields, new
constraints, etc.).

Any suggestions or opinions would be greatly appreciated.

Thanks

Cor Ligthert [MVP]
5/7/2007 12:00:00 AM
Brooke,

Inline

[quoted text, click to view]
Should not be any problem

[quoted text, click to view]
Here are typed datasets even better because you are direct told that there
is a problem by only one time building your project.

Just my thought,

Cor

Miha Markic
5/7/2007 12:00:00 AM

[quoted text, click to view]

Yep, there is no limitation. But note, that you can create multiple
datasets, each one per problem domain.
IOW you are not forced to have one gigantic typed dataset, I would vota
against such approach.

[quoted text, click to view]

Cor is right, but only if you modify typed dataset. Let's say you have
changed column name in database. Next you have to find all occurrences in
your typed datasets and change columns accordingly. Only then, you'll get
compile time errors where you were using the old column name, and this is
good - you'll catch errors asap.
You are also right that keeping typed datasets in sync with database is an
effort. There are a couple of solutions, though:
a) create typed datasets using some sort of generator (there are some
generators out there, both free and commercial, CodeSmith (commercial)
highly recommended)
b) forget classic ado.net approach and switch to an ORM approach (there is
plenty of ORMs out there, both free and commercial, LLBLGenPro (commercial)
highly recommened)
--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
AddThis Social Bookmark Button