Last post Aug 04, 2011 03:45 PM by LudovicoVan
Aug 01, 2011 02:32 PM|msinca|LINK
Newbie question: I'm setting up a new ASP.Net site with a SQL Server 2008 DB. Pretty simple site (gridviews, forms, insert, edit, delete) with maybe 20 tables. All of the access/updates will be done using Stored Procedures in SQL Server.
I know there are many ways to 'skin the cat' when it comes to getting data on the page and I'm currently evaluating 2 of them (typed datasets and using the Enterprise Library's Data Access component).
Is there a general preference or recommondation to using something like the typed Dataset objects (.xsd) or should I use something like the Enterprise Library's Data Access component to get the data in my codebehind pages? Are there any performance or security
benefits of using one vs the other?
Thanks in advance,
Aug 01, 2011 04:57 PM|atconway|LINK
Personally I would prefer to work with custom entity classes rather than typed datasets. Using strongly typed object collections have the benefit of allowing OOP with full blown classes rather than ADO.NET dataset objects. You could use LINQ to DataSets
to populate your entities, and then use List(Of <T>) object collections to persist up-wards as they can be bound to your ASP.NET controls.
As for Enterprise Library for getting the data, that is a fine idea. It is more about how you shape, use, and interact with that data (DataSets vs. Custom Entities) that is more in question. Or another option would be to use an ORM like the Entity
Framework which will take a lot of the manual work out of getting the data and creating your entities as it will do it for you.
Regardless of the option you select, I would use custom classes as opposed to any type of DataSet, to work with the data
after retrieving it from the database.
For a little more information, take a look at the following (2) links:
.NET Object Collections 101:
How To: Populate a List of Objects from a DataSet Using LINQ:
Aug 02, 2011 04:00 PM|msinca|LINK
I really appreciate your answer. Is there a specific reason why you use the Custom class vs Typed Datasets? I would assume that you have 100% control of the code and you don't have to worry about the 'behind the scenes' code found in Typed Datasets. Are
there also performance benefits or any other reason to do so?
Aug 03, 2011 05:00 PM|atconway|LINK
Is there a specific reason why you use the Custom class vs Typed Datasets?
Typed DataSets do not allow you to harness the full potential of object oriented programming like custom classes do. Concepts like Inheritance, Polymorphism, Encapsulation, etc. are not feasible with ADO.NET objects (like DataSets, DataTables, etc) only.
Many of the widely used design patterns and architectures used and documented will work nicely around and within your custom classes, but not with DataSets alone.
Keep in mind a DataSet object can still be used to be populated with data from the database. However, after retrieving the data you should map it to your own objects. An easy way to do this is with LINQ to DataSets, allowing to create strongly typed lists
of objects in relatively few lines of code. Another option as I mentioned previously is to use the Entity Framework to wrap retrieving and entity mapping for you. Either method though will not rely on the DataSet solely.
Aug 04, 2011 03:45 PM|LudovicoVan|LINK
Well, I still have to see a scenario where typed datasets make sense (over untyped datasets and custom objects), although that might be me. OTOH, please note that the DAAB also provides methods to map result sets to custom objects and collections, so there
is no need to reinvent the wheel on top of that. -- So for the original question, of course the DAAB is the approach I would suggest.