DataSet vs Custom Entities

转载 2007年10月01日 16:30:00

DataSet vs Custom Entities

In these days I’ve read many different opinions about DataSet and Custom Entities. Here is my personal point of view.

 

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

 

A typed DataSet allows us to handle data in a more abstract way, even if there’s a DataSet under the cover, we can think and write code in terms of Objects (rows) made of Fields (columns) grouped in Collections (tables).

Thanks to the handling of data as collections of typed objects we can trap errors while in compile-time rather then in runtime.

For instance if we use a classic DataSet on a table that has an integer idCustomer column:

 

ds.Tables[0].Rows[5]["idCustomer"] = 5;

ds.Tables[0].Rows[5]["idCustomer"] = "Foo";

 

we’ll get an exception on the second row just during runtime.

With a typed DataSet:

ds.Customers[5].idCustomer = 5;

ds.Customers[5].idCustomer = "Foo";

 

we’d have a compilation error. It sounds better of course, especially when on the presentation layer there’re developers that have a little knowledge about the data structure.

From a data binding point of views typed DataSet are equivalent to classic DataSet.

On the other side using a typed DataSet doesn’t change the size of the serialization result.

A Web Service based on typed DataSet is still not WS-I compliant and not SOA oriented.

Anyway we can override its XmlSerialization, re-implementing IXmlSerializable and customizing the auto generated WSDL, in order to make it readable by other platforms, for instance Java with AXIS even if we’ve no guarantee to be WS-I BP1 compliant and SOA designed. I always say that we’re not obliged to design and develop services WS-I BP1 compliant and/or SOA architected above all if we don’t need it… you know, but I always also say that services world is following the SOA and WS-I way, are you sure that your services won’t do that sooner or later?

Custom Entities

 

Custom Entities are usually slim, from an XmlSerialization point of view, and there are also tools, like System.Xml.Serialization attributes, to make it even slimmer.

We’ve to pay the due to fill the entities with our data, being careful of not building monster with multiple heads, with GB and GB of RAM filled with data that should be kept inside the DBMS engine. Remember that custom entities are the containers of small instance data and not a replacement for your DBMS, like DataSet as well, of course!

In order to develop WS-I BP1 and SOA compliant services, custom entities are the right choice. It’s enough to design in the right way your messages, as XSD, and to describe your contracts with custom WSDL.

We’re able to easily data bind a custom entity in ASP.NET presentation layer; on the other side it’s not so easy or quick to bind a Windows Forms presentation app.

 

So, what’s the best choice?

 

The answer is: “It depends J !”

Why “it depends”?

 

First of all I think that we need to identify the target of our discussion:

1) Windows Forms application inside a LAN with 2-tier architecture (client/server)

2) Windows Forms application inside a LAN with n-tier architecture

3) ASP.NET Web Application

 

If you’re in the first situation … don’t care about that, just use a DataSet. Anyway think about the reasons that made you do not choose n-tier architecture ….

In the second case it’s better to consider custom entities, not only from a bandwidth point of view (remember that custom entities are generally smaller than DataSet) but also from an architectural point of view (only data layer should have knowledge about your real data structure) and, if you’re using Web Service, above all from a SOA and WS-I point of view. On the other side you’ll pay your choice in terms of data binding pains. In fact data binding in Windows Forms using a custom entity is not easy as with a DataSet.

In the last situation I’d like to decide carefully every single time I need to make this kind of choice. It depends on the size of your data, of your database, the portability of your architecture from ASP.NET to other presentation tiers, etc.

 

We also need to think a bout who will write the presentation layer:

1) People with knowledge about the data structures

2) BIZ and DAL are written by people different than the presentation layer group, so they have different knowledge about the data structures

 

In the first situation we’re free to choose the best solution for our project. In the second case we need to keep in mind that an object model (with VS.NET intellisense) is easier to use than a general purpose DataTable in a DataSet, so at least a typed DataSet or a custom entity will probably be my choice. Remember also, as I’ve already said, that data layer should be the only one layer to have complete knowledge about the data structure.

 

Then if we need to make our data available through web services we need to care of the real targets of our services:

1) Only a .NET node

2) Any kind of SOAP node

3) Any WS-I BP1 compliant node

 

In the first situation we need first of all to think about why we choose a Web Service … I mean: if you need to speak from .NET to .NET Web Services are not the only way we have. We’ve also .NET Remoting, Serviced Components, SOAP Services based on WSE2, etc. Of course may be that a Web Service is the right choice for your project, nut think about that, don’t just use it as a default answer.

By the way if we decided to use a Web Service to decouple our .NET layers, but we know that .NET will always be the only choice in our life J … sometimes we can think about using DataSet and/or typed DataSet in order to have easier access from the presentation layer, to data binding features. On the other side keep in mind that Web Services that handle DataSet and typed DataSet are verbose.

In the second and third case I always choose custom entities because this is the only way to be really interoperable and WS-I BP1 and SOA compliant. In the third case I always start designing messages (XSD) and contracts (WSDL) and just at the end I develop the underlying code.

At least we need to think about who will query the BIZ layer:

1) ASP.NET

2) Windows Forms

3) Both of them

4) Many different kind of apps

 

I’ve already showed you my opinion for the first and second case.

In the third situation custom entities are more expensive, in term of  code to write, than DataSet or typed DataSet, but are more portable and somehow maintainable.

In the fourth case is often mandatory to make an abstraction over the data structure, in order to make possible to use the BIZ layer with many different applications and types of applications.

Anyway I really don’t like to have a default answer for any situation; I always prefer to think carefully about all different pros and cons, to always try to get the best.

 

 

 

 

 

 

pytorch学习笔记(六):自定义Datasets

自定义Datasets什么是Datasets:在输入流水线中,我们看到准备数据的接口是这么写的data = datasets.CIFAR10("./data/", transform=transfor...
  • u012436149
  • u012436149
  • 2017年04月04日 13:31
  • 5102

C#:DataSet控件(数据控件)

DataSet控件是ADO.NET结构的主要组件,它是从数据源中检索到的数据在内存中的缓存。DataSet由一组DataTable对象组成,可以使这些对象与DataRelation对象互相关联。还可以...
  • vjudge
  • vjudge
  • 2014年07月23日 23:20
  • 2051

谈谈RDD、DataFrame、Dataset的区别和各自的优势

在spark中,RDD、DataFrame、Dataset是最常用的数据类型,本博文给出笔者在使用的过程中体会到的区别和各自的优势   共性: 1、RDD、DataFrame、Dat...
  • xgjianstart
  • xgjianstart
  • 2017年05月16日 20:00
  • 337

VS可视化调试学习总结

.NET开发人员必备的可视化调试工具 (你值的拥有) http://sanwen8.cn/p/52airn6.html http://www.cnblogs.com/cyq1162/p/6027051...
  • bcbobo21cn
  • bcbobo21cn
  • 2016年12月16日 10:19
  • 1599

易混HTML Entities与正确使用方法

在页面上,表示HTML实体有多种方式,比如有“&+name;”、“&#+10进制ID”、“&#x+16进制ID”。而“\u+16进制”一般用于CSS的content样式属性。空字符 – null空字符...
  • woxueliuyun
  • woxueliuyun
  • 2015年12月22日 15:58
  • 1979

C#之数据集:DataSet对象

ADO.NET数据访问技术的一个突出的特点就是支持离线访问,而实现这种离线访问技术的核心就是DataSet对象,该对象通过将数据驻留在内存来实现离线访问。         DataSet对象概述 ...
  • erlian1992
  • erlian1992
  • 2015年05月26日 17:14
  • 2091

JSON序列化与反序列化DataSet

一、序列化一个DataSet 1.首先创建一个DataSet对象. using System; using System.Collections.Generic; using System.Linq;...
  • lovegonghui
  • lovegonghui
  • 2015年12月10日 14:24
  • 683

数据存储---内存列式数据库KDB+(Q)文档

Kx systems公司的创始人之一Arthur Whitney在2003年研发了列式数据库KDB和它的操作语言Q。    官网:www.kx.com 主要Feature: 内存内的数据库:理解...
  • hugolyl
  • hugolyl
  • 2015年10月30日 14:35
  • 2075

VS自定义工程向导开发(Custom Wizard)

   在vs2010中定制VC++工程向导有如下两种方式: 修改现有向导,以满足自己的需要; 使用“自定义向导”来产生一个向导骨架,并设计自己的向导。 ...
  • hudfang
  • hudfang
  • 2015年03月18日 14:39
  • 895

entity framework 6.0 复杂条件的两种调用方式

 共同的部分 OrderModelField omf1 = new OrderModelField("Fbqssj", true);//多个字段排序 OrderModel...
  • laokaizzz
  • laokaizzz
  • 2014年06月04日 18:14
  • 1349
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:DataSet vs Custom Entities
举报原因:
原因补充:

(最多只允许输入30个字)