置顶随笔
#
摘要: 对于所有的开发人员来说，Exception Handling是我们每天都要面对的事情。对于基于Source Code的Exception Handling，我想大家已经司空见惯了，但是对于Database级别的Exception Handling，就没有那么常见了。在这篇文章中，我将会介绍我对于基于Database编程中Exception Handling的一些粗浅的认识：在编写Stored Procedure时，如何抛出一个可预知的Exception，ADO.NET如何处理从Database抛出的Exception，如何保存基于Database Exception的Error Message，如何在Database和.NET Application之间进行消息的传递[注：这里的Database主要指SQL Server]。
阅读全文
摘要: 《我的WCF之旅》系列自开篇以来，得到了园子里很多朋友的厚爱，并荣登了博客园2007年度系列博文Top 10。由于工作原因，沉寂了一阵，两个月前开始WCF新的旅程。如果说《我的WCF之旅》主要是对WCF基本原理概括性介绍，而对于这个新的系列，我将和大家分享我对WCF的一些实现机制、设计原理的理解，以及我在实际的项目开发中的一些实践经验（比如在后续的一些文章中，我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能）。
阅读全文
摘要: Policy Injection Application Block（PIAB）是Enterprise Library众多Application Block中的一个。在我看来，PIAB和后来的Unity Application Block的推出在Enterprise Library的发展历程中具有重要的意思，它标志着Enterprise Library向真正框架上面发展。不再是仅仅关注于某个具体功能实现（比如Logging、Caching、DA、Security等等）。PIAB提供了一种易用的、可扩展的机制是你能够将你需要的Policy应用到对应的目标对象上。PIAB是为你实现AOP提供了又一个不错的选择。对了让读者全面地了解PIAB，能够灵活的使用PIAB为你项目开发服务，我先后写了6篇文章。现在将他们集中在一起，以飨读者。
阅读全文
摘要: 较之C# 2.0, C# 3.x引入了一些列新的特性，为我们编程带来很大的便利，通过有效地利用这些新特性，我们可以编写出更加简洁、优雅的程序。不过这些新特性仅仅是编译器给我们耍的小花招：在编译的时候加入一些必要的Code，使这些在C# 2.0角度看略显残缺的Code变得“完整”，实际上最终生成的Assembly和在C# 2.0时代并没有本质的不同。为此，有些人对这些新特性不以为然，觉得仅仅是一些表面文章，是鸡肋。但是我的观点是：既然这些特性能给我们的编程带来便利，干嘛不用呢？
阅读全文
摘要: WCF是构建和运行Connected System的一些列技术的总称，它是建立在Web Service Architecture上的一个全新的Communication Infrastructure。你可以把它看成是.NET平台上的新一代的Web Service。WCF为我们提供了Secure & Reliable的Messaging，也为我们提供了更好的Interoperability是的我们可以和其他的平台进行互操作。
在过去半年之后，我陆陆续续写了一些关于WCF介绍的一些文章，我把它命名为“我的WCF之旅”，目的在于向大家分享我学习WCF这一段旅程。现在把把这个系列做一个阶段性的总结，以飨读者。这个总结并不是意味着我将结束这个系列，这个系列还会继续，新加的内容我会补上。
阅读全文
2008年9月26日
#
摘要: 微软Enterprise Library ELAB（Exception Handling Application Block）提供了一种基于策略（Policy）的异常处理方式，在不同的环境中，比如多层架构中不同的层次中，我们可以定义不同的异常处理策略。对于ELAB来说，Exception Handling Policy = Exception Type + Exception Handler(s) ，也就是说异常处理策略规定了对于某种类型的类型需要通过那些Exception Handler去处理。从这种意义上讲，ELAB的异常处理机制是基于Exception Type的，异常的类型是我们处理异常的最小粒度。对于一个确定的异常处理策略，在不同场合抛出的同种类型的异常，都会使用相同的Exception Handler去处理。在很多情况下，这种基于异常类型级别的异常处理并不能解决我们实际异常处理的问题。我们往往需要粒度更细的异常处理机制——对于抛出的同一种类型的异常，根据异常对象具体的属性值进行相应的异常处理。
阅读全文
2008年9月22日
#
摘要: WCF的通信是基于消息的，如果从消息交换（message exchange）的角度讲，信道层则可以看成是进行消息交换参与者之间的中介。信道层通过一个个信道组成一个连续的channel stack，该channel stack构成了一个消息流通的管道。消息的发送者通过该管道流到消息的接收者，消息的接收者对消息进行相应的处理，生成新的消息通过该管道回复给消息的发送者。本文将着重介绍WCF中的Binding模型，从该模型中，读者将会对WCF如何通过Binding创建channel stack的整个过程有一个大致的了解。
阅读全文
2008年9月19日
#
摘要: 对于希望对WCF的消息交换有一个深层次了解的读者来说，tcpTracer绝对是一个不可多得好工具。我们将tcpTracer置于服务和服务代理之间，tcpTracer会帮助我们接获、显示和转发流经他的消息。 从本质上讲，tcpTracer是一个路由器。当启动的时候，我们需要设置两个端口:原端口（source port）和目的端口（destination port），然后tcpTracer就会在原端口进行网络监听。一旦请求抵达，他会截获整个请求的消息，并将整个消息显示到消息面板上。随后，tcpTracer会将该消息原封不动地转发给目的端口。在另一方面，从目的端口发送给原端口的消息，也同样被tcpTracer截获、显示和转发。
阅读全文
2008年9月18日
#
摘要: 在上一篇介绍
逻辑地址和物理地址文章中,我们介绍了终结点的ListenUriMode, 我们提到了两个特殊的对象ChannelDispatcher和ChannelListener。这两个对象在整个WCF的消息分发系统中具有重要的地位，在这节里，我们对WCF的整个消息分发过程作一个简单的介绍。
阅读全文
2008年9月17日
#
摘要: 在WCF中，每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址，对于消息发送放来讲，就是消息被真正发送的目的地址；而对于消息的接收放来讲，就是监听器真正监听的地址...
阅读全文
2008年9月16日
#
摘要: 在一般的网络环境中，尽可能避免网络攻击，都会通过防火墙将绝大部分的端口封掉，仅仅保留那些常用的网络服务所用的端口，或者为某一个类应用保留少量的端口。总而言之，我们不能保证每个跨防火墙通信的应用都具有一个唯一的端口，他们只能共享一个或者少量的几个端口。 无论是基于Intranet还是Internet，无论是采用何种传输协议，端口共享——让多个网络应用程序使用相同的端口进行通信，都具有重要的现实意义。
对于采用不同的传输协议，我们有不同的解决方案，对于HTTP协议，我们可以通过IIS的寄宿方式实现端口的共享，对于TCP，.NET Framework3.0提供了一个特殊的Windows服务，Net.TCP Port Sharing Service，帮助我们轻松的实现端口的共享。我们接下来就讨论这种端口共享解决方案
阅读全文
2008年9月2日
#
摘要: 在
Part I 中，我们创建了一个InterceptService，并且通过一个特殊的EndpointBehavior，ClientViaBehavior实现了message的拦截、转发功能。在本节中，我们将讨论另外一种不同的实现方式。如何说ClientViaBehavior是基于Client端的实现方式，那么我们今天讨论的是基于Service的实现方式。
阅读全文
2008年9月1日
#
摘要: WCF是.NET平台下实现SOA的一种手段，SOA的一个重要的特征就基于Message的通信方式。从Messaging的角度讲，WCF可以看成是对Message进行发送、传递、接收、基础的工具。对于一个消息交换的过程，很多人只会关注message的最初的发送端和最终的接收端。实际上在很多情况下，在两者之间还存在很多的中间结点（Intermediary），这些中间结点在可能在实际的应用中发挥中重要的作用。比如，我们可以创建路由器（Router）进行消息的转发，甚至是Load Balance；可以创建一个消息拦截器（Interceptor）获取request或者response message，并进行Audit、Logging和Instrumentation。今天我们就我们的目光转向这些充当着中间人角色的Intermediary上面来。
阅读全文
2008年8月28日
#
摘要: 对于所有的开发人员来说，Exception Handling是我们每天都要面对的事情。对于基于Source Code的Exception Handling，我想大家已经司空见惯了，但是对于Database级别的Exception Handling，就没有那么常见了。在这篇文章中，我将会介绍我对于基于Database编程中Exception Handling的一些粗浅的认识：在编写Stored Procedure时，如何抛出一个可预知的Exception，ADO.NET如何处理从Database抛出的Exception，如何保存基于Database Exception的Error Message，如何在Database和.NET Application之间进行消息的传递[注：这里的Database主要指SQL Server]。
阅读全文
2008年8月26日
#
摘要: 《我的WCF之旅》系列自开篇以来，得到了园子里很多朋友的厚爱，并荣登了博客园2007年度系列博文Top 10。由于工作原因，沉寂了一阵，两个月前开始WCF新的旅程。如果说《我的WCF之旅》主要是对WCF基本原理概括性介绍，而对于这个新的系列，我将和大家分享我对WCF的一些实现机制、设计原理的理解，以及我在实际的项目开发中的一些实践经验（比如在后续的一些文章中，我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能）。
阅读全文
2008年8月25日
#
摘要: 在本系列的上一篇文章中,我们重点讨论了线程关联性对service和callback的操作执行的影响:在service host的时候，可以设置当前线程的SynchronizationContext，那么在默认情况下，service操作的执行将在该SynchronizationContext下执行（也就将service操作包装成delegate传入SynchronizationContext的Send或者Post方法）.对于Windows Form Application来讲，由于UI Control的操作执行只能在control被创建的线程中被操作，所以一这样的方式实现了自己的SynchronizationContext（WindowsFormsSynchronizationContext）：将所有的操作Marshal到UI线程中。正因为如此，当我们通过Windows Form Application进行WCF service的host的时候，将会对service的并发执行带来非常大的影响。
阅读全文
2008年8月22日
#
摘要: 最近在做一个Smart Client Software Factory的项目。熟悉SCSF或者CAB的都应该很清楚MVP这种设计模式。MVP是MVC的一种变体，View和Mode分别关注于UI的呈现和业务模型，View和Mode完全分离，View通过Presenter实现对业务模型的访问，Presenter“间接”地调用View实现对UI的操作。对于MVP中的异常处理，我们是直接通过Enterprise Library的Exception Handling Application Block来实现的。具体的做法是：在View中的每个控件的事件中添加try/catch block， 并在catch中通过ExceptionPolicy实现对异常的处理。这样导致的问题是，相同的代码重复散
阅读全文
2008年8月21日
#
摘要: 对于一般的多线程操作，比如异步地进行基于文件系统的IO操作；异步地调用Web Service；或者是异步地进行数据库访问等等，是和具体的线程无关的。也就是说，对于这些操作，任意创建一个新的线程来执行都是等效的。但是有些情况下，有些操作却只能在固定的线程下执行。比如，在GUI应用下，对控件的访问就需要在创建该控件的线程下执行；或者我们在某个固定的线程中通过TLS（Thread Local Storage）设置了一些Context信息，供具体的操作使用，我们把操作和某个固定的线程的依赖称为线程关联性（Thread Affinity）。在这种情况下，我们的异步操作就需要被Marshal到固定的线程执行。在WCF并发或者Callback的情况下也具有这样的基于线程关联性的问题。
阅读全文
2008年8月11日
#
摘要: 对于一个真正的企业级的应用来说，Caching肯定是一个不得不考虑的因素，合理、有效地利用Caching对于增强应用的Performance（减少对基于Persistent storage的IO操作）、Scalability（将数据进行缓存，减轻了对Database等资源的压力）和Availability（将数据进行缓存，可以应对一定时间内的网络问题、Web Service不可访问问题、Database的崩溃问题等等）。Enterprise Library的Caching Application Block为我们提供了一个易用的、可扩展的实现Caching的框架。借助于Caching Application Block，Administrator和Developer很容易实现基于Caching的管理和编程。由于Caching的本质在于将相对稳定的数据常驻内存，以避免对Persistent storage的IO操作的IO操作，所以有两个棘手的问题：Load Balance问题；Persistent storage和内存中数据同步的问题。本篇文章提供了一个解决方案通过SqlDependen
阅读全文
2008年8月8日
#
摘要: Policy Injection Application Block（PIAB）是Enterprise Library众多Application Block中的一个。在我看来，PIAB和后来的Unity Application Block的推出在Enterprise Library的发展历程中具有重要的意思，它标志着Enterprise Library向真正框架上面发展。不再是仅仅关注于某个具体功能实现（比如Logging、Caching、DA、Security等等）。PIAB提供了一种易用的、可扩展的机制是你能够将你需要的Policy应用到对应的目标对象上。PIAB是为你实现AOP提供了又一个不错的选择。对了让读者全面地了解PIAB，能够灵活的使用PIAB为你项目开发服务，我先后写了6篇文章。现在将他们集中在一起，以飨读者。
阅读全文
2008年8月6日
#
摘要: Enterprise Library是微软P&P部门开发的众多Open source框架中的一个，最新的版本已经出到了4.0。由于接触Enterprise Library已经有很长的一段时间，在实际的项目中使用的频率也很高。对此有了一些积累，希望通过这个新的系列和广大网友一起分享和交流。本系列假设读者已经对Enterprise Library有一定的了解，故而不会对各个Application Block的基本原理和编程模型进行介绍，而把侧重点放在Enterprise Library深层次的实现原理、设计模式的应用、有效扩展和最佳实践上。今天我们讨论的内容是如何通过自定义UnityContainerExtension实现Unity和PIAB的集成.
阅读全文
2008年8月5日
#
摘要: 对于PerCall这种实例化方式来说，为每次service请求都创建新的service instance，有时候显得有点极端，频繁的对象创建会对系统的性能造成一定的影响。我们能够以池的机制进行对象的获取和创建呢：当service调用请求抵达service端，先试图从池中获取一个没有被使用的service instance，如何找到，直接获取该对象；否则创建新的对象。当service instance对象执行完毕，将对象释放到池中以供下次service 调用使用。
阅读全文
2008年8月4日
#
摘要: 我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。
阅读全文
摘要: 我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。
阅读全文
2008年7月30日
#
摘要: 在最近的一个Smart Client项目中，为了演示异步操作的实现，写了一个基于BackgorundWorker的例子。由于这个理基本上实现了BackgorundWorker的大部分功能：异步操作的启动、操作结束后的回调、异步操作的撤销和进度报告等等。尽管没有太多的技术含量，姑且放上来与大家分享。
阅读全文
2008年7月29日
#
摘要: 在上一篇文章中，我们通过自定义InstanceProvider实现了WCF和微软Enterprise Library Unity Application Block的集成， 今天我们已相同的方式实现WCF与Enterprise Library的另一个Application Block的集成：Policy Injection Application Block (PIAB)。
阅读全文
2008年7月28日
#
摘要: 松耦合、高内聚是我们进行设计的永恒的目标，如何实现这样的目标呢？我们有很多实现的方式和方法，不管这些方式和方法在表现形式上有什么不同，他们的思想都可以表示为：根据稳定性进行关注点的分离或者分解，交互双方依赖于一个稳定的契约，而降低对对方非稳定性因素的依赖。从抽象和稳定性的关系来讲，抽象的程度和稳定程度成正相关关系。由此才有了我们面向抽象编程的说法，所以“只有依赖于不变，才能应万变”... ...
阅读全文
2008年7月24日
#
摘要: 在上一篇文章中，我们讨论了如何通过CallContextInitializer实现Localization的例子，具体的做法是将client端的culture通过SOAP header传到service端，然后通过自定义的CallContextInitializer设置当前方法执行的线程culture。在client端，当前culture信息是通过OperationContext.Current.OutgoingMessageHeaders手工至于SOAP Header中的。实际上，我们可以通过基于WCF的另一个可扩展对象来实现这段逻辑，这个可扩展对象就是MessageInspector。我们今天来讨论MessageInspector应用的另外一个场景：如何通过MessageInspector来传递Context信息。
阅读全文
2008年7月17日
#
摘要: 在上一篇文章中, 我列出了WCF一系列的可扩展对象和元素，并简单介绍了他们各自的功能、适合的场景和具体解决的问题。从本篇开始我将通过一个个具体的例子来介绍如何利用这些扩展点对WCF进行扩展，从而解决一些我们在实现的项目开发中可能出现的问题。
阅读全文
2008年7月16日
#
摘要: 在本系列的每篇文章中，我多次提到WCF是一个极具可扩展性的分布是消息通信框架。为了让读者对WCF Extension有一个总体的的认识，在这里我会简单列举了我们经常使用的绝大部分的扩展点，以及通过这些扩展点能够解决实现项目开发中的那些问题。
阅读全文
2008年7月15日
#
摘要: 在本系列的第一部分、第二部分中，我们对WCF的channel layer进行了深入的讨论。我们接下来继续讨论WCF的ser vice mode layer。本篇文章着重介绍service 端的ServiceMode。写作此篇文章旨在达到以下两个目的：
希望读者对ServiceMode有一个大致的了解，结合前面介绍的channel layer的相关知识，帮助读者了解WCF的整个实现机制和执行的流程。
介绍ServiceMode涉及到的绝大部分extension point，让读者在具体的项目开发中能够根据实际的需要灵活、自由地对WCF进行扩展。
阅读全文
2008年7月9日
#
摘要: 在上一篇文章中，我们通过一个直接借助BasicHttpBinding对象实现Client和Server端进行通信的例子，对WCF channel layer进行了一个大致上的介绍。由此引出了一些列通信相关的概念和对象，比如Channel，Output channel， Input channel，Request channel, Reply Channel，Duplex channel， Channel Shape，Channel manager，Channel factory, Channel listener, Binding element 等。通过这些元素，我们很容易地实现对WCF channel layer进行扩展。
在本章节中，我们将继续讨论WCF channel layer。我们将通过如何创建和应用custom channel来介绍channel layer一些知识。
阅读全文
2008年7月8日
#
摘要: 《我的WCF之旅》系列自开篇以来，得到了园子里很多朋友的厚爱，并荣登了博客园2007年度系列博文Top 10。由于工作原因，沉寂了几个月，今天开始WCF新的旅程。如果说《我的WCF之旅》主要是对WCF基本原理概括性介绍，而对于这个新的系列，我将和大家分享我对WCF的一些实现机制、设计原理的理解，以及我在实际的项目开发中的一些实践经验（比如在后续的一些文章中，我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能）。
阅读全文
2008年2月21日
#
摘要: PIAB为我们提供了一个很好地实现AOP的方式。AOP旨在实现Business Logic和Non-Business Infrastructure Logic的分离。通过PIAB，我们将这些业务无关的逻辑定义在一个个的CallHandler中，然后通过Attribute或者Configuration的方式，将我们所需的CallHandler运用到相应的目标对象中。从这个意义上讲，PIAB具有很好的Flexibility和Extensibility。但是，就我看来PIAB也具有一些不足之处，其最大的局限性在于：不能控制运用到某个Method的多个方法的执行顺序。而让CallHandler按照我们希望的顺序进行调用是非常有必要的。
阅读全文
2008年2月19日
#
摘要: 本系列的
第一部分对PIAB使用场景进行了简单的介绍，作中阐述了通过PI（Policy Injection）的方式实现了Business Logic和Non-Business Infrastructure Logic的分离，从而实现了AOP（Aspect Oriented Programming）。在
第二部分中详细介绍PIAB的实现机制：通过自定义RealProxy的方式实现了Method Injection。通过这几天接收到的网友的留言，觉得很多人对在具体的项目开发中如何使用PIAB还有很多困惑，对PIAB的价值还不是很了解。为此，在本系列的第三篇文章中，我将以Walk through的方式定义一个Custom CallHa
阅读全文
2008年1月31日
#
摘要: 在
前面一篇文章中，我对Enterprise Library中的PIAB （Policy Injection Application Block）作了简单的介绍。在这篇文章主要谈谈我个人对PIAB设计和实现原理的一些理解。在介绍过程中，我尽量采用由浅入深出的方式，同时结合例子、Source Code。希望通过本片文章让大家对PIAB有一个全面、深刻的认识。
阅读全文
2008年1月29日
#
摘要: 在过去的半年里，定期或者不定期地写点东西已经成为了我的一种习惯。可是最近两个月来一直忙于工作的事情一直足够的时间留给自己，虽然给自己列了很长一串写作计划，可是心有余而力不足。这一段工作主要是帮助公司开发一套分布式的开发框架，对一些技术和设计方法有了一些新的认识。这两天的工作主要是如何把Enterprise Library V3.1的PIAB（Policy Injection Application Block）引入到我们自己的框架中，为此对PIAB进行了一些研究，借此机会与大家一起分享。
阅读全文
2007年12月17日
#
摘要: 在
谈谈基于SQL Server 的Exception Handling - PART II中，我给出了一个完整的例子说明了：如何在将message定义在sys.messages中保证message的一致性和可维护性；如何在Stored procedure中使用RAISERROR将一个可预知的Error抛出；如何在Stored procedure中使用TRY/CATCH进行异常的捕捉；在Application如果处理从SQL Server抛出的Exception。实际上，SQL Server database Engine抛出、被我们的.NET最终捕获的SqlException，我们通过SqlException的属性可以得到Error的相关信息。下面是SqlException的属性列表：
阅读全文
摘要: 在
上面一节中，我通过RAISERROR重写了创建User的Stored procedure，实际上上面的Stored procedure是有问题的。我之所以没有立即指出，是因为这是一个很容易犯的错误，尤其是习惯了.NET Exception Handling的人更容易犯这样的错误。我们知道在.NET Application中，如果出现一个未处理的Exception，程序将立即终止，后续的程序将不会执行，但是对于上面的SQL则不一样，虽然我们通过RAISERROR将Error抛出，但是SQL的指定并不会被终止，INSERT语句仍然会被执行的。我想很多人会说在RAISERROR后加一个Return就可以了嘛。不错这是一个常用的解决方案，但是我不倾向于使用这种方法。为了更清楚地说明这个问题，我们举另一个相关的例子，上面我们介绍了创建User的例子，我们现在来引入另一个例子：如何将一个User添加到一个Role里面
阅读全文
摘要: 对于所有的开发人员来说，Exception Handling是我们每天都要面对的事情。对于基于Source Code的Exception Handling，我想大家已经司空见惯了，但是对于Database级别的Exception Handling，就没有那么常见了。在这篇文章中，我将会介绍我对于基于Database编程中Exception Handling的一些粗浅的认识：在编写Stored Procedure时，如何抛出一个可预知的Exception，ADO.NET如何处理从Database抛出的Exception，如何保存基于Database Exception的Error Message，如何在Database和.NET Application之间进行消息的传递[注：这里的Database主要指SQL Server]。
阅读全文
2007年11月27日
#
摘要: 软件工程是一门独特的工程艺术，需要解决的是不断改变的需求变化。而对于WCF，对于SOA，由于涉及的是对多个系统之间的交互问题，如何有效地解决不断改变的需求所带来的问题就显得更为重要：Service端版本的变化能否保持现有Consumer的正常调用，Consumer端的改变不至于影响对Service 的正常调用。对于Data Contract来说就是要解决这样的问题：Service端或者Client对Data Type的改变不会影响Service的正常调用。
在系统开发过程中，通过对Data Type添加额外的字段进而对其进行扩展，是一个种很常见的场景。本部分就作中介绍Data Contract的这种变化，Service或者Client的Data Contract在本地添加一个新的Data Member会造成怎样的影响，WCF可以采用怎样的机制来解决这种单方面Data Contract版本的改变。
阅读全文
摘要: 在本篇文章上一部分Order Processing的例子中，我们看到原本已Collection形式定义的DetailList属性（public IList
DetailList），在Data Contract中却以Array的方式体现（public OrderDetail[] DetailList）。我们现在就来详细地讨论一下基于Collection & Dictionary 的Data Contract。 阅读全文
摘要: 通过第一部分的介绍，我们可以体会到，WCF 的Data Contract在CLR Type和Neutral Contract之间搭建了一座桥梁，弥合了.NET世界和厂商中立世界的差异。通过WCF Data Contract我们将CLR Data Type暴露成一个厂商中立的数据结构的描述，同样通过WCF Data Contract我们将一个现有的CLR Data Type和既定的Neutral contract进行适配。
在.NET中，基于Primary Type，比如Int32，String等等，他们具有一个简单的默认的序列化方式和结构，可以说他们不需要Data Contract。接下来我们主要讨论的是一些相对比较特殊的、完全基于.NET的Data Type，比如Generic、Collection，和Dictionary。首先，我们结合例子来谈谈基于Generic的Data Type的Data Contract。
阅读全文