Geeks With Blogs
Saqib Ullah BootStrapper Know How

Almost as common as the debate over which .NET language to choose is the argument about whether to use DataSets or not. As described above, typed data sets are easy to generate through the designer, provide a type safe API for containing business entity data, and already support advanced features such as change tracking, sorting, filtering, and searching. Some of the resistance to DataSets resulted from several performance shortcomings in the .NET 1.1 implementations. These problems included poor performance when working with large DataSets and the fact that DataSets always serialized themselves as XML, which had bandwidth and performance implications when passing DataSets across remoting boundaries. These problems have been fixed in .NET 2.0 and there have been a large number of other improvements.

The alternative to using DataSets is to create custom object types that represent your business entities, and custom collection types to contain them. When you go this route, you end up needing to write a lot more code yourself. This has gotten a lot better in Visual Studio 2005 and .NET 2.0 with the additions of code snippets and generic collection classes. But to support the full range of features that a DataSet provides, there is still a fair amount of custom code that you will need to write by hand.

Custom objects have the advantage of giving you explicit and complete control over the way the type is designed, what its internal capabilities are, and what the API is that is exposed from the object. If you prefer a pure object-oriented design approach, then custom business entities will feel a little more comfortable to you. You can accomplish almost anything with a typed data set that you can with a custom business entity, but some things may be a little less clean with a typed data set if the things you are trying to do don’t map well to the relational nature of a typed data set. But if you are primarily getting business data for the purposes of presenting the data, allowing the user to work with the data, and then will persist the data back to the database, you will be able to get things done quicker with typed data sets if you harness the features of the DataSet designer.

When you go with typed data sets in Visual Studio 2005, you can actually support most of the same design styles that you could with custom business entity types. The data access code will always be separated into the table adapter types generated by the designer, or into data access components that you write. But you can add custom validation and other logic into your business entity types (the typed data row or data table classes) through partial class extensions. Each of the types created as part of a typed data set definition (data set, data table, data row, and table adapter) are defined in the generated code as partial classes. This feature in .NET 2.0 allows you to supplement the designer generated code with custom code that becomes part of the compiled type, but you do so through a separate code file. This prevents your code from being destroyed if you choose to regenerate the designer generated code. For more information on partial types, see the MSDN library documentation for .NET 2.0.

Another argument that comes up a lot against using DataSets is the assertion that if you are using DataSets in your presentation or business layer, then you are tightly coupling your application to the data tier. This does not have to be the case. First off, you should consider using stored procedures as a layer of decoupling between your actual data tier schema and your application. Your stored procedures can then return and work with result sets that map well to the business entities that you will be manipulating in your application. Additionally, if you need to provide additional decoupling beyond what the stored procedures provide, you can transform data that has been placed into a DataSet into either a different (decoupled) typed data set definition or a custom business entity type in your business or data access layer.

One final thing to point out has to do with returning DataSets from web services. There is a strong argument that you should never return a DataSet from a web service method. Never is a strong word in design, but if you want to support a true service-oriented paradigm with your web services, I would have to agree with this guidance. Typed data sets do introduce both a type coupling and a .NET technology coupling for any clients of that service, which is something you should avoid in a service-oriented world. If your client is a .NET client, it is fairly simple to consume the proxy generated version of the typed data set on the client side, and there is little harm if you are willing to lock yourself into only .NET clients. But in general you should think twice before exposing a DataSet as a type on a web service contract, and favor not doing so.

If you want to achieve maximum productivity in building a .NET application, and can live with the limitations described in this section, then typed data sets are a great capability that you should consider exploiting in your .NET applications where it makes sense. One of the biggest wins in using typed data sets in Visual Studio 2005 is the fact that it also generates a table adapter class, which is like a typed data adapter, for each table in the data set. The designer allows you to very quickly create customized query methods in the table adapter that makes it so you will rarely have to write any ADO.NET code yourself if you are working with typed data sets.

Posted on Wednesday, March 21, 2007 8:14 PM .Net , General | Back to top


Comments on this post: DS vs. BO

# re: DS vs. BO
Requesting Gravatar...
good site!
study!
Left by 数据恢复 on Apr 28, 2007 6:00 PM

Your comment:
 (will show your gravatar)


Copyright © Saqib Ullah | Powered by: GeeksWithBlogs.net