Dataset vs Business Entities

Introduction

This days creating a layered architectured applications is common and widely used. A distributed application always need to send data from one layer to another. If you are an .Net developer and you've come to a cross roads of sorts in development over which object model to go with. thier are multiple options available but the formal and first question we need to ask ourselves is what are we going to do with our data. the best two options available are using dataset or create business entities which will hold data. using dataset also gives as option of selecting a untyped dataset or typed dataset.

Before selecting a data tier component following are the point which we must keep in mind

• 1) use of application(internal or external)
• 2) deadline of the application
• 3) development efforts(resources required)
• 4) Architectural design of application
• 5) how future changes will be implmented

thier may be many other scenarios which must be taken on consideration. let us see what this option are and how are they achieved.

Dataset

DataSet are not particularly optimized when you serialize them with either XmlSerializer or Formatters runtime serialization, at least until the release of .NET Framework 2.0...
By default XmlSerialization of DataSets is a little bit fat J, because of its Schema, Data and DiffGram representation. To tell the true we can refine XmlSerialization of DataSet implementing IXmlSerializable interface in custom DataSet or typed DataSet.
On the other side re-implementing IXmlSerialization is not always trivial and sometime it’s simply too expensive if compared to the goal we’d like to achieve.
In order to use a DataSet inside the presentation layer, we need to have knowledge about data structures (i.e. tables, columns and rows hosted by the DataSet), so we don’t have real abstraction from the data layer.
Anyway a DataSet makes easier to develop data binding code not only in ASP.NET but above all in Windows Forms apps.
From a Web Service point of view a DataSet fights with SOA, with WS-I BP1 and with any other kind of SOAP node that’s not .NET based.

Typed DataSet

the diffrence here in typed dataset is that we define the structure of the data at design time which gives us a more abstract way of representing data. Typed dataset is type safe and provides us compile time error rather than runtime.

Advantages of using typed dataset

· The readability of our code increases.
· It gives compile time error for datatype mismatch.
· With Visual Studio 2005 you will get the intellisense support for tables and columns.

Business entities

Creating a business entities requires more effort and development time, but it has less overhead in terms of memory and performance. Custom entities are slim and effiecent way of passing data. the over head here is to create custom classes and implementing serialization mechanism. Relation of the data also must be implemented seperately. A future change also need to be take care as all the business entities class should be changed.

When new requirement must be handled,

Fastest Development Time :- Typed Dataset

Requires Custom Programming for filter and sort :- Business Entity

Requires Re-deploying Client To Add New Column :- Typed Dataset,Business Entity

Requires Re-deploying Service To Add New Column :- Dataset,Typed Dataset,Business Entity

Heaviest Payload: - Dataset

Conclusion

The best approach a developer can take when it comes to Datasets vs the entity argument is take a holistic approach at the problem that he or she is trying to be solve. Don't forget to take into account future changes and how much maintenance may be required. Use common sense and match the best solution to the problem. I hope this helps and is now officially clear as mud.