摘要： 今天看到看到一篇MSDN文章《Parallelizing Operations With Dependencies》,作者是微软Parallel Computing Platform团队的一个开发经理。文中提供出一种用于并行执行一组具有依赖关系的操作的解决方案，这不由得想起我在一年之前写的一个具有相同的功能的组件。于是翻箱倒柜找了出来，进行了一些加工，与大家分享一下。 阅读全文

摘要： 开门见山，下面的例子中通过调用ThreadPool.QueueUserWorkItem(WaitCallback callBack, object state)的方式实现异步调用： List actions = new List(); //...... foreach (var action in actions) { ThreadPool.QueueUserWorkItem(state = action(), null); } Console.Read(); 但是出现错误的输出结果...... 阅读全文

摘要： Why don't you partition your table if you have millions of rows and get complaints about the degradation of performance? This is the question I asked my friend and I was amazed to find out he, along with many people, wasn't aware of this feature of SQL Server. This feature was first made available in SQL Server 2005, and today I will discuss what partitioning is. 阅读全文

摘要： Are you creating a new Web site and developing a user registration system that requires new visitors to sign-up and create a user ID and password? Stop now and read this. There are now more effective approaches for dealing with Web accounts which are more powerful and are better for you and your users... 阅读全文

摘要： 开门见山，使用MS Enterprise Library的DAAB（Data Access Application Block）获取数据时抛出异常。具体场景如下，通过Database对象的ExecuteReader执行两段Select语句，前一句是不合法的，后一句是正确的。为了避免第一次执行出错导致程序的终止，特意将其放到Try/Catch酷快中。两次数据库操作通过TrsanctionScope的形式纳入同一个Transaction中，具体的代码如下所示。 阅读全文

摘要： In the last year or so, after quite a lull, the software architecture business has gotten rather exciting again. We're finally seeing major new topics emerging into the early mainstream that are potential game-changers, while at the same time a few innovations that have been hovering in the margins of the industry are starting to break out in a big way. The big changes: The hegemony of traditio 阅读全文

摘要： 由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟... ... 阅读全文

摘要： 在上面的内容中，先后介绍了信道、信道管理器、信道监听器和信道工厂。从对象的创建来讲，信道管理器是信道的创建者。说的再具体点，客户端的信道通过信道工厂创建，服务端的信道通过信道监听器创建。但是信道工厂和信道监听器又是如果被创建出来的呢？ 我们在一开始就已经说过，作为终结点三要素的绑定对象实现了所有的通信细节，并且通过创建信道栈实现了消息的传递。从这一点来说，绑定对象无疑是信道层所有通信对象的最终缔造者，所以信道工厂和信道监听器最终的创建都是靠绑定对象实现的。关于这个创建过程又和另一个重要的对象密切相关，那就是绑定元素。 阅读全文

摘要： 由于信道管理器在客户端和服务端所起的不同作用，分为信道监听器和信道工厂。和服务端的信道监听其相比，处于客户端的信道工厂显得简单。从名称就可以看得出来，信道工厂的作用就是单纯的创建用于消息发送的信道。我们先来看看与信道工厂相关的一些接口和基类的定义。 阅读全文

摘要： 基于Enterprise Library PIAB的AOP框架已经在公司项目开发中得到广泛的使用，但是最近同事维护一个老的项目，使用到了Enterprise Library 2，所以PIAB是在Enterprise Library 3.0中推出的，所以不同直接使用。为了解决这个问题，我写了一个通过方法劫持（Method Interception）的原理，写了一个简易版的AOP框架。 阅读全文

摘要： 信道管理器是信道的创建者，一般来说信道栈的中每个信道对应着一个信道管理器。基于不同的消息处理的功能，将我们需要将相应的信道按照一定的顺序能组织起来构成一个信道栈，由于信道本身是由信道管理器创建的，所以信道对应的信道管理器也构成一个信道管理器栈，栈中信道管理器的顺序决定由它所创建信道的顺序。 对于WCF的信道层来说，信道管理器在服务端和客户端扮演着不同的角色，服务端的信道管理器在于监听来自客户端的请求，而客户端的信道仅仅是单纯的创建用于消息发送的信道。因此，客户端的消息管理器又称为信道监听器（Channel Listener），客户端的信道管理器则成为信道工厂（channel factory）。 阅读全文

摘要： 这个工具执行一组批处理，也可以看成是一个Sequential Workflow的执行器，我把它成为Batch Job Executor。在使用Batch Job Executor过程中，通过配置可以对批处理的每个步骤、或者是Workflow的每个Activity进行自由地定义。从功能上将，这个小工具仅仅是个小玩意儿，不登大雅之堂。 不过考虑到Batch Job Executor的涉及和实现是基于Enterprise Library典型的实现方式，比如基于EL的配置和对象创建方式，对于那些希望进一步了解EL的读者，或许可以通过这个小小的例子一窥EL的设计原理。对于那些EL的设计不时很了解的读者，对于以下的内容，可能在理解上可能比较困难。最好是下载源代码，结合下面的介绍，希望会帮助了更好的理解EL。 阅读全文

摘要： WCF采用基于消息交换的通信方式，而绑定则实现了所有的通信细节。绑定通过创建信道栈实现了消息的编码与传输，以及对WS-*协议的实现。在这一节中，我们就来着重介绍WCF中的信道和信道栈。 阅读全文

摘要： 下面通过一个简单的Console Application演示Type Innitializer的执行顺序。希望大家各抒己见，对于实验的结果给出一个圆满的解释，同时希望读者从中理解到更多关于编译、关于CLR一些被我们忽略的细节。 阅读全文

摘要： [From J.D Meier’s Blog:http://blogs.msdn.com/jmeier/default.aspx] Today we released our patterns & practices App Arch Guide 2.0 Beta 1. This is our guide to help solution architects and developers make the most of the Microsoft platform. It's a distillation of many lessons learned. It’s principle-based and pattern-oriented to provide 阅读全文

摘要： 对于稍微有点经验的.NET开发人员来说，倘若被问及如何保持线程同步，我想很多人都能说好好几种。在众多的线程同步的可选方式中，加锁无疑是最为常用的。如果仅仅是基于方法级别的线程同步，使用System.Runtime.CompilerServices.MethodImplAttribute无疑是最为简洁的一种方式。MethodImplAttribute可以用于instance method，也可以用于static method。当在某个方法上标注了MethodImplAttribute，并指定MethodImplOptions.Synchronized参数，可以确保在不同线程中运行的该方式以同步的方式运行。我们几天来讨论MethodImplAttribute（MethodImplOptions.Synchronized）和lock的关系。 阅读全文

摘要： 微软Enterprise Library ELAB（Exception Handling Application Block）提供了一种基于策略（Policy）的异常处理方式，在不同的环境中，比如多层架构中不同的层次中，我们可以定义不同的异常处理策略。对于ELAB来说，Exception Handling Policy = Exception Type + Exception Handler(s) ，也就是说异常处理策略规定了对于某种类型的类型需要通过那些Exception Handler去处理。从这种意义上讲，ELAB的异常处理机制是基于Exception Type的，异常的类型是我们处理异常的最小粒度。对于一个确定的异常处理策略，在不同场合抛出的同种类型的异常，都会使用相同的Exception Handler去处理。在很多情况下，这种基于异常类型级别的异常处理并不能解决我们实际异常处理的问题。 阅读全文

摘要： WCF的通信是基于消息的，如果从消息交换（message exchange）的角度讲，信道层则可以看成是进行消息交换参与者之间的中介。信道层通过一个个信道组成一个连续的channel stack，该channel stack构成了一个消息流通的管道。消息的发送者通过该管道流到消息的接收者，消息的接收者对消息进行相应的处理，生成新的消息通过该管道回复给消息的发送者。本文将着重介绍WCF中的Binding模型，从该模型中，读者将会对WCF如何通过Binding创建channel stack的整个过程有一个大致的了解。 阅读全文

摘要： 对于希望对WCF的消息交换有一个深层次了解的读者来说，tcpTracer绝对是一个不可多得好工具。我们将tcpTracer置于服务和服务代理之间，tcpTracer会帮助我们接获、显示和转发流经他的消息。 从本质上讲，tcpTracer是一个路由器。当启动的时候，我们需要设置两个端口:原端口（source port）和目的端口（destination port），然后tcpTracer就会在原端口进行网络监听。一旦请求抵达，他会截获整个请求的消息，并将整个消息显示到消息面板上。随后，tcpTracer会将该消息原封不动地转发给目的端口。在另一方面，从目的端口发送给原端口的消息，也同样被tcpTracer截获、显示和转发。 阅读全文

摘要： 在上一篇介绍逻辑地址和物理地址文章中,我们介绍了终结点的ListenUriMode, 我们提到了两个特殊的对象ChannelDispatcher和ChannelListener。这两个对象在整个WCF的消息分发系统中具有重要的地位，在这节里，我们对WCF的整个消息分发过程作一个简单的介绍。 阅读全文

摘要： 在WCF中，每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址，对于消息发送放来讲，就是消息被真正发送的目的地址；而对于消息的接收放来讲，就是监听器真正监听的地址... 阅读全文

摘要： 在一般的网络环境中，尽可能避免网络攻击，都会通过防火墙将绝大部分的端口封掉，仅仅保留那些常用的网络服务所用的端口，或者为某一个类应用保留少量的端口。总而言之，我们不能保证每个跨防火墙通信的应用都具有一个唯一的端口，他们只能共享一个或者少量的几个端口。 无论是基于Intranet还是Internet，无论是采用何种传输协议，端口共享——让多个网络应用程序使用相同的端口进行通信，都具有重要的现实意义。 对于采用不同的传输协议，我们有不同的解决方案，对于HTTP协议，我们可以通过IIS的寄宿方式实现端口的共享，对于TCP，.NET Framework3.0提供了一个特殊的Windows服务，Net.TCP Port Sharing Service，帮助我们轻松的实现端口的共享。我们接下来就讨论这种端口共享解决方案 阅读全文

摘要： 在Part I 中，我们创建了一个InterceptService，并且通过一个特殊的EndpointBehavior，ClientViaBehavior实现了message的拦截、转发功能。在本节中，我们将讨论另外一种不同的实现方式。如何说ClientViaBehavior是基于Client端的实现方式，那么我们今天讨论的是基于Service的实现方式。 阅读全文

摘要： WCF是.NET平台下实现SOA的一种手段，SOA的一个重要的特征就基于Message的通信方式。从Messaging的角度讲，WCF可以看成是对Message进行发送、传递、接收、基础的工具。对于一个消息交换的过程，很多人只会关注message的最初的发送端和最终的接收端。实际上在很多情况下，在两者之间还存在很多的中间结点（Intermediary），这些中间结点在可能在实际的应用中发挥中重要的作用。比如，我们可以创建路由器（Router）进行消息的转发，甚至是Load Balance；可以创建一个消息拦截器（Interceptor）获取request或者response message，并进行Audit、Logging和Instrumentation。今天我们就我们的目光转向这些充当着中间人角色的Intermediary上面来。 阅读全文

摘要： 对于所有的开发人员来说，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实现一些在真正的分布式项目开发中很有现实意义的功能）。 阅读全文

摘要： 在本系列的上一篇文章中,我们重点讨论了线程关联性对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进行W 阅读全文

摘要： 最近在做一个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实现对异常的处理。这样导致的问题是，相同的代码重复散 阅读全文

摘要： 对于一般的多线程操作，比如异步地进行基于文件系统的IO操作；异步地调用Web Service；或者是异步地进行数据库访问等等，是和具体的线程无关的。也就是说，对于这些操作，任意创建一个新的线程来执行都是等效的。但是有些情况下，有些操作却只能在固定的线程下执行。比如，在GUI应用下，对控件的访问就需要在创建该控件的线程下执行；或者我们在某个固定的线程中通过TLS（Thread Local Storage）设置了一些Context信息，供具体的操作使用，我们把操作和某个固定的线程的依赖称为线程关联性（Thread Affinity）。在这种情况下，我们的异步操作就需要被Marshal到固定的线程执行。在WCF并发或者Callback的情况下也具有这样的基于线程关联性的问题。 阅读全文

摘要： 对于一个真正的企业级的应用来说，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 stor 阅读全文

摘要： 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篇文章。现在将他们集中在一起，以飨读者。 阅读全文

摘要： Enterprise Library是微软P&P部门开发的众多Open source框架中的一个，最新的版本已经出到了4.0。由于接触Enterprise Library已经有很长的一段时间，在实际的项目中使用的频率也很高。对此有了一些积累，希望通过这个新的系列和广大网友一起分享和交流。本系列假设读者已经对Enterprise Library有一定的了解，故而不会对各个Application Block的基本原理和编程模型进行介绍，而把侧重点放在Enterprise Library深层次的实现原理、设计模式的应用、有效扩展和最佳实践上。今天我们讨论的内容是如何通过自定义UnityContainerExtension实现Unity和PIAB的集成. 阅读全文

摘要： 对于PerCall这种实例化方式来说，为每次service请求都创建新的service instance，有时候显得有点极端，频繁的对象创建会对系统的性能造成一定的影响。我们能够以池的机制进行对象的获取和创建呢：当service调用请求抵达service端，先试图从池中获取一个没有被使用的service instance，如何找到，直接获取该对象；否则创建新的对象。当service instance对象执行完毕，将对象释放到池中以供下次service 调用使用。 阅读全文

摘要： 我们都知道，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管理。 阅读全文

摘要： 在最近的一个Smart Client项目中，为了演示异步操作的实现，写了一个基于BackgorundWorker的例子。由于这个理基本上实现了BackgorundWorker的大部分功能：异步操作的启动、操作结束后的回调、异步操作的撤销和进度报告等等。尽管没有太多的技术含量，姑且放上来与大家分享。 阅读全文

摘要： 在上一篇文章中，我们通过自定义InstanceProvider实现了WCF和微软Enterprise Library Unity Application Block的集成， 今天我们已相同的方式实现WCF与Enterprise Library的另一个Application Block的集成：Policy Injection Application Block (PIAB)。 阅读全文

摘要： 松耦合、高内聚是我们进行设计的永恒的目标，如何实现这样的目标呢？我们有很多实现的方式和方法，不管这些方式和方法在表现形式上有什么不同，他们的思想都可以表示为：根据稳定性进行关注点的分离或者分解，交互双方依赖于一个稳定的契约，而降低对对方非稳定性因素的依赖。从抽象和稳定性的关系来讲，抽象的程度和稳定程度成正相关关系。由此才有了我们面向抽象编程的说法，所以“只有依赖于不变，才能应万变”... ... 阅读全文

摘要： 在上一篇文章中，我们讨论了如何通过CallContextInitializer实现Localization的例子，具体的做法是将client端的culture通过SOAP header传到service端，然后通过自定义的CallContextInitializer设置当前方法执行的线程culture。在client端，当前culture信息是通过OperationContext.Current.OutgoingMessageHeaders手工至于SOAP Header中的。实际上，我们可以通过基于WCF的另一个可扩展对象来实现这段逻辑，这个可扩展对象就是MessageInspector。我们今天来讨论MessageInspector应用的另外一个场景：如何通过MessageInspector来传递Context信息。 阅读全文

摘要： 在上一篇文章中, 我列出了WCF一系列的可扩展对象和元素，并简单介绍了他们各自的功能、适合的场景和具体解决的问题。从本篇开始我将通过一个个具体的例子来介绍如何利用这些扩展点对WCF进行扩展，从而解决一些我们在实现的项目开发中可能出现的问题。 阅读全文