WCF服务端运行时架构体系详解
WCF服务端运行时架构体系详解
发布时间：2011年12月26日
第一部分
WCF的服务端架构体系又可以成为服务寄宿端架构体系。我们知道，对于一个基于某种类型的服务进行寄宿只需要使用到一个唯一的对象，那就是ServiceHost。甚至在某种语境下，我们所说的服务实际上就是指的对应的ServiceHost对象。整个服务寄宿过程包括两个阶段，即服务描述的创建和服务端运行框架的建立。而第一个阶段创建的服务描述是为了第二个阶段对服务端运行时框架建立服务的，所以我们有必要在对服务描述进行简单的介绍。
目录：
一、从服务描述（Service Description）谈起
二、服务端架构体系概览
三、终结点分发器选择机制
一、从服务描述（Service Description）谈起
当ServiceHost在被实例化的过程中，用于描述整个服务的ServiceDescription对象被创建出来。对于一个服务来说，它的核心包括：一组终结点列表和一组服务行为列表。这可以通过如下所示的ServiceDescription的定义看出来。
public class ServiceDescription
{
//其他成员
public ServiceEndpointCollection Endpoints { get; }
}
而对于终结点来说，对于它的ABC三要素，即地址（Address）、绑定（Binding）和契约（Contract）早已了然于胸了。所以用于描述终结点的ServiceEndpoint类型具有Address、Binding和Contract三个核心属性。此外还有基于该终结点的行为列表，通过Behaviors属性表示。ServiceEndpoint的定义如下所示。
public class ServiceEndpoint
{
//其他成员
public EndpointAddress Address { get; set; }
public Binding Binding { get; set; }
public ContractDescription Contract { get; }
public KeyedByTypeCollection
}
现在我们进一步分析用以描述服务契约的ContractDescription类型。由于服务契约本质上是一组相关操作的组合，所以ContractDescription的核心属性是如下所示的表示所有操作描述的Operations属性。除了操作描述列表之外，自然还有基于服务契约本身的行为列表。
public class ContractDescription
{
//其他成员
public OperationDescriptionCollection Operations { get; }
}
至于对服务操作的描述，对应的类型为OperationDescription。OperationDescription中定义了一系列基于服务操作的属性，它们以及在之前的章节有过详细的介绍了，在这里我们主要关注的是用以表示操作行为列表的属性Behaviors。
public class OperationDescription
{
//其他成员
public KeyedByTypeCollection
}
上述从服务ServiceDescription到ServiceEndpoint，从ServiceEndpoint到ContractDescription，最终到OperationDescription的层次结构基本上可以通过下图来表示。
在构建ServiceHost过程中创建的用于描述整个服务的ServiceDescription对象，最终成为了构建服务端运行时架构体系的基础。而该架构体系在ServiceHost开启的过程中被构建出来，这也是为什么在ServiceHost开启之后对服务描述所作的任何该表都是无效的根本原因。
二、服务端架构体系概览
为了让读者对服务端运行时架构体系的结构具有更加深刻的认识，我们针对一个具体的服务寄宿应用场景来进行介绍。假设我们采用如下的配置对服务CalculatorService进行寄宿。通过这段配置，三个基于WSHttpBinding的终结点被添加。
binding = "wsHttpBinding" contract = "Artech.WcfServices.ICalculator" listenUri = "http://127.0.0.1:6666/CalculatorService" listenUriMode= "Explicit"/> binding = "wsHttpBinding" contract = "Artech.WcfServices.ICalculator" listenUri = "http://127.0.0.1:6666/CalculatorService" listenUriMode= "Explicit"/> binding = "wsHttpBinding" contract = "Artech.WcfServices.ICalculator" listenUri = "http://127.0.0.1:6666/CalculatorService" listenUriMode= "Unique"/> 如上面的配置片断所示，虽然这三个终结点具有不同的地址，但是它们却使用了相同的监听URI（通过listenUri属性设置）。进一步地，虽然三个终结点具有相同的监听URI，但是它们的监听URI模式（通 过listenUriMode属性设置），前两个终结点为Explicit，而第三个为Unique。按照在《WCF技术剖析（卷1）》第三章介绍的关于“物理地址和逻辑地址”原理，你会知道在这种情况下，最终的监听地址具有两个：http://127.0.0.1:6666/CalculatorService和 http://127.0.0.1:6666/CalculatorService/< 当基于上面配置创建的ServiceHost在正常开启后，WCF会创建如下图所示的架构体系。首先通过调用绑定的BuildChannelListener方法创建信道监听器（实际上是多个信道监听器构成的信道监听器栈，最终返回的是最上层的信道监听器。如果读者对于信道层的相关内容不是特别了解，请参考《WCF技术剖析（卷1）》第3章《绑定与信道栈》）。这两个信道监听器分别绑定到上述的两个监听地址进行请求消息的监听。 针对这两个信道监听器，WCF会创建相应的信道分发器（ChannelDispatcher）对象。而针对在配置中定义的三个终结点，它们则分别对应着一个终结点分发器（EndpointDispatcher）。每个终结点分发器分发器都具有各自的运行时，被称为分发运行时（DispatchRuntime）。 当信道监听器成功监听到抵达的请求消息，它会利用创建的信道栈对消息进行接收和处理。经过信道栈处理过的消息通过信道监听器所在的信道分发器转发给相应的终结点分发器。终结点最终将接收到的消息在自 己的分发运行时中进行处理。而处理后的结果被封装在创建的回复消息中回传给信道分发器，并最终通过信道栈返回给客户端。那么现在有一个问题：信道监听器在接收到经过信道栈接收和处理的消息后，如果判断需要将消息转发给哪个终结点分发器呢？这就是涉及到终结点分发器的选择机制。 三、终结点分发器选择机制 我们将注意力再次返回到上图。你会发现除了分发运行时，每个终结点分发器还具有两个重要的对象：地址筛选器（AddressFilter）和契约筛选器（ContractFilter）。它们都是属于一个叫做消息筛选器（MessageFilter）的对象。信道分发器就是通过这两个消息筛选器最终决定所在的终结点分发器是否适合处理当前请求消息。 具体来说，每个消息筛选器均继承自Dispatcher.MessageFilter这个抽象类。MessageFilter具有两个重载的分别以Message和MessageBuffer作为参数的方法。信道分发器在决定应该将接收的消息路由给哪个终结点分发器之前，会将基于路由消息的Message或者MessageBuffer对象作为输入参数，调用所有终结点分发器两个消息筛选器的Match方法。如果方法方法返回True，则表明该终结点分发器与需要路有的消息匹配。 public abstract class MessageFilter { public abstract bool Match(Message message); public abstract bool Match(MessageBuffer buffer); } 终结点分发器在WCF的应用编程接口中通过类型 System.ServiceModel.Dispatcher.EndpointDispatcher表示。EndpointDispatcher的部分定义如下面的代码片断所示，除了代表上述两个消息筛选器的两个属性AddressFilter和ContractFilter之外，还 有一个额外的整型的FilterPriority属性。FilterPriority属性表示筛选的优先级，当两个以上终结点分发器同时与路由的消息匹配的情况下，由优先级最高的终结点分发器会被选用。代表FilterPriority的数据越大，意味着优先级越高。如果同时有两个或者以上具有最高筛选优先级的终结终结点分发器，系统会抛出一个MultipleFilterMatchesException异常。 public class EndpointDispatcher { //其他成员 public MessageFilter AddressFilter { get; set; } public MessageFilter ContractFilter { get; set; } public int FilterPriority { get; set; } } 为了满足各种消息理由的需要，WCF为我们定义了如下六种典型的消息消息筛选器。如果这6种消息筛选器依然不能满足你的需求，你可以通过继承MessageFilter这个抽象类创建你自定义的消息筛选器。 ?ActionMessageFilter：每一个服务操作具有一个Action属性，通过 OperationContractAttribute特性进行定义。一个服务契约包含一个或者多个服务操作，所以 一个终结点具有一组Action列表。AddressMessageFilter通过判断SOAP消息的Action报 头的值是否在终结点Action列表之中，从而选择正确的终结点 ?EndpointAddressMessageFilter：EndpointAddress是一个终结点不可或缺的元素，EndpointAddress不仅包含服务的地址，也包含寻址的报头（AddressHeader），能够通过 EndpointAddressMessageFilter筛选的终结点需要同时满足两个要求：终结点地址URI需要 与SOAP的To报头值一致；SOAP消息具一致的报头信息 ?XPathMessageFilter：SOAP消息也是一个XML，所以可以根据一个具体的XPath表达式和SOAP的内容进行匹配 ?PrefixEndpointAddressMessageFilter：和EndpointAddressMessageFilter筛选机制类似，不同的是PrefixEndpointAddressMessageFilter采用“最长前缀匹配”机制。比如，终结点地 址指定的URI为https://www.sodocs.net/doc/c44165632.html,/Foo，而请求消息的To报头的URI为 https://www.sodocs.net/doc/c44165632.html,/Foo/Bar，这样可以被认为是匹配的 ?MatchAllMessageFilter：不管消息的内容是什么，都会匹配成功 ?MatchNoneMessageFilter：和MatchAllMessageFilter相反，不管消息的内容是什么，都不会匹配成功 在默认的情况下，EndpointDispatcher的AddressFilter和ContractFilter分别采用的是EndpointAddressMessageFilter和ActionMessageFilter。如果希望使用其他的值，可以通过自定义Behavior的形式覆盖掉默认的值。对于AddressFilter，最直接的方式就是通过ServiceBehaviorAttribute的AddressFilterMode属性指定你所需要的MessageFilter模式。该属性的类型为AddressFilterMode枚举。它具有三个枚举值（Exact、Prefix和Any）对应于EndpointAddressMessageFilter、PrefixEndpointAddressMessageFilter和MatchAllMessageFilter这三种消息筛选器。 public sealed class ServiceBehaviorAttribute : Attribute, IServiceBehavior { //其他成员 public AddressFilterMode AddressFilterMode { get; set; } } public enum AddressFilterMode { Exact, Prefix, Any } 第二部分 这篇文章中，我们对信道分发器本身作一个深入的了解，首先来看看它具有哪些可供扩展的组件，以及我们可以针对信道分发器对WCF实现哪些可能的扩展。 目录： ErrorHandler & ServiceThrottle ChannelInitializer IncludeExceptionDetailInFaults ManualAddressing MaxPendingReceives ReceiveSynchronously IsTransactedReceive & MaxTransactedBatchSize TransactionIsolationLevel & TransactionTimeout 信道分发器对应的类型为ChannelDispatcher，下面的代码片断给出ChannelDispatcher部分属性成员的定义。而这些属性代表了包含在信道分发器中那些可供扩展的组件。信道分发器是基于信道监听器创建的，后者用于请求消息的监听和消息接收信道栈的创建。信道监听器对应于只读属性Listener。public class ChannelDispatcher : ChannelDispatcherBase { //其他成员 public SynchronizedCollection public Collection public ServiceThrottle ServiceThrottle { get; set; } publicoverride IChannelListener Listener { get; } } ErrorHandler & ServiceThrottle 而属性ErrorHandlers代表的是一组ErrorHandler对象的集合。而ErrorHandler用于异常的处理的错误消息的提供。而类型为ServiceThrottle的同名属性用于进行流量控制，相关的内容你也可以参考《WCF中并发（Concurrency）与限流（Throttling）》。 ChannelInitializer 至于属性ChannelInitializers，则代表的是一组实现了接口 System.ServiceModel.Dispatcher.IChannelInitializer的被称为信道初始化器的对象。顾名思义，所谓信道初始化器，就是当服务信道被创建之后用于对其进行初始化操作。接口IChannelInitializer的定义如下，它只具有一个唯一的Initialize方法。 public interface IChannelInitializer { void Initialize(IClientChannel channel); } 从扩展性角度来讲，你可以将自定义的ErrorHandler和ServiceThrottle应用到信道分发器中分别实现对异常的处理和流量的控制。你也可以自定义信道初始化器改变创建的信道状态。上述的关于信道分发器的结构可以简单地通过下图表示。 信道分发器结构为了实现自定义的异常处理和流量扩展等功能，你可以将自定义的相关组件应用到信道分发器中。另一方面，信道分发器本身具有一些用于控制器运行行为的属性。你也可以根据需要改变这些属性是信道分发器按照你希望的行为进行运作。下面的代码片断列出了信道分发器主要的可供修改的属性。其中通过属性MessageVersion表示的消息的版本（SOAP版本和WS-Addressing版本）决定于绑定的同名属性。public class ChannelDispatcher : ChannelDispatcherBase { //其他成员 public bool IncludeExceptionDetailInFaults { get; set; } public bool ManualAddressing { get; set; } public MessageVersion MessageVersion { get; set; } public int MaxPendingReceives { get; set; } public bool ReceiveSynchronously { get; set; } public bool IsTransactedReceive { get; set; } public int MaxTransactedBatchSize { get; set; } public IsolationLevel TransactionIsolationLevel { get; set; } public TimeSpan TransactionTimeout { get; set; } } IncludeExceptionDetailInFaults IncludeExceptionDetailInFaults：表示服务端抛出的异常的详细信息是否需要通过错误消息回传给客户端。基于安全的需要，该属性的默认值为False。通常只有在调试的时候我们才需要让客户端得到服务端原始的错误信息，所以这个开关由服务行为ServiceDebugBehavior来控制。如下面的代码所示，ServiceDebugBehavior具有一个同名的属性。你也可以直接通过在服务类型上应用ServiceBehaviorAttribute特性通过命名属性控制这个开关。关于该属性背后的原理，你可以参考我的文章《ServiceDebugBehavior服务行为是如何实现异常的传播的?》 public class ServiceDebugBehavior : IServiceBehavior { //其他成员 public bool IncludeExceptionDetailInFaults { get; set; } } public sealed class ServiceBehaviorAttribute : Attribute, IServiceBehavior { //其他成员 public bool IncludeExceptionDetailInFaults { get; set; } } ManualAddressing 而属性ManualAddressing则涉及到寻址（Addressing）的概念。对于一个支持WS-Addressing 的SOAP消息来说，在其报头列表中包括一系列WS-Addressing报头（比如To、ReplyTo、RelatesTo 等）以提供消息路由需要的寻址信息。在默认的情况下，这些寻址报头最终是通过位于信道栈最底层的传 输信道（Transport Channel）来添加的。但是在某些情况下，我们希望手工地位消息添加相应的寻址报头，并希望该消息按照这些手工添加的寻址信息进行路由。我们将这种机制成为手工寻址（Manual Addressing）。 如果启用手工寻址，当消息最终通过传输信道向传输层发送的时候，传输信道会认为相应的寻址报头已经被成功添加，所以不会进行寻址报头的重复添加。ChannelDispatcher的ManualAddressing属性表示是否启用了手工寻址，其默认值决定于绑定的传输绑定元素的同名属性。按照寻址的需要，你可以在运行时动态变该属性值强制启用或者禁用手工寻址。 public abstract class TransportBindingElement : BindingElement { //其他成员 public bool ManualAddressing { get; set; } } MaxPendingReceives MaxPendingReceives表示允许的最大挂起（未处理）的消息数，默认值为1。该值可以通过终结点行为DispatcherSynchronizationBehavior来修改。如下所示，DispatcherSynchronizationBehavior 具有一个同名的属性。 public class DispatcherSynchronizationBehavior : IEndpointBehavior { //其他成员 public int MaxPendingReceives { get; set; } } ReceiveSynchronously 对于服务端信道层对请求消息的接收，到底采用同步还是异步的方式更加有效往往取决于具体采用的通信方式。在默认的情况下，对于同步/异步消息接收方式的选择取决于终结点的绑定。对于所有的系统预定义绑定类型，它们都实现了一个特殊的接口IBindingRuntimePreferences。如下面的代码片断所示，IBindingRuntimePreferences接口具有一个唯一的只读属性：ReceiveSynchronously。该属性就表示具体的绑定是否应该采用同步的消息接收方式。而在默认的情况下，绑定的ReceiveSynchronously属性值被作为对应的信道分发器的同名属性值。 public interface IBindingRuntimePreferences { bool ReceiveSynchronously { get; } } 对于几个我们常用的系统预定义绑定（BasicHttpBinding、WSHttpBinding、WSHttp2007Binding、WSDualHttpBinding、NetTcpBinding、NetNamedPipeBinding和NetMsmqBinding），除了NetMsmqBinding的ReceiveSynchronously属性可以是True外，其他绑定的该属性总是返回False。也就是说，除了NetMsmqBinding，其他的绑定总是以异步的方式进行消息的接收，这样可以及时地处理同时抵达的消息请求，并极大的改善服务的吞吐量。而对于NetMsmqBinding来说，它的ReceiveSynchronously属性和ExactlyOnce具有相同的值。 虽然在默认的情况下，绑定的ReceiveSynchronously属性决定了信道分发器的同名属性。但是你也可以通过扩展来改变该属性值。实际上，WCF为我们定义了一个类型为 System.ServiceModel.Description.SynchronousReceiveBehavior的终结点行为来对信道分发器的ReceiveSynchronously属性值进行设定。当终结点应用了该行为之后，对应的信道分发器被自动设置为True，意味着采用同步的方式接收请求消息。 IsTransactedReceive & MaxTransactedBatchSize 接下来，我们来关于信道分发器与事务相关的几个属性。首先是基于事务的消息接收。为了判断某个绑定是否支持事务性消息接收，WCF定义了名称为 System.ServiceModel.Channels.ITransactedBindingElement的接口。从下面给出的定义可以看出，ITransactedBindingElement具有唯一的只读属性TransactedReceiveEnabled，表明是否需要将消息的接收工作纳入到事务中进行。 public interface ITransactedBindingElement { bool TransactedReceiveEnabled { get; } } 从接口的名称我们就可以看出来，ITransactedBindingElement是为绑定元素定义的接口。对于一个具体的绑定来说，只要它的绑定元素列表中具有任何一个绑定元素实现了ITransactedBindingElement接口，并且TransactedReceiveEnabled属性返回True，就意味着这是一个基于事务性消息接收的绑定。而绑定的是否支持事务性消息接收在默认的情况下反应在信道分发器的IsTransactedReceive属性上，而另一个属性MaxTransactedBatchSize则表示允许纳入同一个事务进行的最大消息接收操作数。对于WCF预定义的所有绑定元素，只有基于MSMQ的两个绑定元素MsmqTransportBindingElement和MsmqIntegrationBindingElement实现了ITransactedBindingElement接口。 对于最初决定于绑定的这两个基于事务性消息接收的属性，我们也可以通过扩展对其进行动态修改以强制或者避免进行事务性消息接收。而对于MaxTransactedBatchSize属性的设定，WCF同样为我们定义了相应的终结点属性：System.ServiceModel.Description.TransactedBatchingBehavior。信道分发器的MaxTransactedBatchSize对应于TransactedBatchingBehavior的MaxBatchSize属性。public class TransactedBatchingBehavior : IEndpointBehavior { //其他成员 public int MaxBatchSize { get; set; } } TransactionIsolationLevel & TransactionTimeout 如果你阅读看了我的文章《WCF事务编程（[上篇]、[中篇]、[下篇]）》你应该对信道分发器的另外两个基于事务的属性TransactionIsolationLevel和TransactionTimeout不会感到陌生。它们代表在事务的隔离级别和超时时限。这两个属性对应于我们熟悉的ServiceBehaviorAttribute特性的同名属性。[AttributeUsage(AttributeTargets.Class)] public sealed class ServiceBehaviorAttribute : Attribute, IServiceBehavior { //其他成员 public IsolationLevel TransactionIsolationLevel { get; set; } public string TransactionTimeout { get; set; } } 第三部分 作为WCF中一个核心概念，终结点在不同的语境中实际上指代不同的对象。站在服务描述的角度，我们所说的终结点实际上是指ServiceEndpoint对象。如果站在WCF服务端运行时框架来说，终结点实际上指代的是终结点分发器（EndpointDispatcher）。而ServiceEndpoint与EndpointDispatcher是一一匹配的，并且前者是创建后者的基础。而终结点分发器具有自己的运行，即分发运行时（DispatchRuntime）。 目录 一、终结点分发器（EndpointDispatcher） 二、分发运行时（DispatchRuntime） 可扩展组件 认证与授权 服务实例上下文 会话关闭通知 同步上下文 消息检验 操作与操作选择 可扩展属性 授权 审核 事务与会话 未处理操作 SOAP ValidateMustUnderstand处理 并发控制 一、终结点分发器（EndpointDispatcher） 除了之前介绍的三个辅助信道分发器向匹配的终结点分发器实施消息路由的三个属性（AddressFilter、ContractFilter和FilterPriority）之外，你还可以通过属性ContractName和ContractNamespace得到服务契约的名称和命名空间，以通过EndpointAddress属性得到相应的终结点地址。将消息路由到该 终结点分发器的信道分发器可以通过属性ChannelDispatcher获得。但是对于终结点分发器来说，其重 要的还是通过属性DispatchRuntime表示的分发运行时。 public class EndpointDispatcher { //其他成员 public string ContractName { get; } public string ContractNamespace { get; } public MessageFilter AddressFilter { get; set; } public MessageFilter ContractFilter { get; set; } public int FilterPriority { get; set; } public ChannelDispatcher ChannelDispatcher { get; } public DispatchRuntime DispatchRuntime { get; } public EndpointAddress EndpointAddress { get; } } 二、分发运行时（DispatchRuntime） 毫不夸张地说，终结点分发器的分发运行时是WCF整个服务端运行时架构体系的核心，同时也是对WCF服务端服务模型进行扩展重点考虑的对象。分发运行时之所以具有如此重要的地位，原因在于：终结点分发器接收到从信道分发器路由的消息的整个处理是在分发运行时中进行的。 可扩展组件 和上面分析信道分发器一样，我们首先来看看分发运行时具有哪些可扩展的组件。终结点的分发运行时对应的类型为DispatchRuntime。下面的代码片断列出了这些扩展组件在DispatchRuntime中的对应的属性定义。 public sealed class DispatchRuntime { //其他成员 public ServiceAuthorizationManager ServiceAuthorizationManager { get; set; } public ServiceAuthenticationManager ServiceAuthenticationManager { get; set; } public RoleProvider RoleProvider { get; set; } public ReadOnlyCollection public IInstanceContextProvider InstanceContextProvider { get; set; } public SynchronizedCollection public InstanceContext SingletonInstanceContext { get; set; } public IInstanceProvider InstanceProvider { get; set; } 分层架构与业务逻辑实现方式 分层架构与业务逻辑实现方式 一、分层架构 在当今软件系统中，常用的软件架构思想就是分层，分层思想是现代软件架构的主要思想。无论是企业级应用系统(如：CRM，ERP，OA，电子商务平台)，专用软件（如：OS、SVN、IDE 等),还有协议之类（TCP/IP，OSI等）绝大部分都采用分层架构思想进行设计的。 分层(Layer)不一定就是人们常说的二，三层，多层系统，因为这些说法都是分层架构的一些具体表现形式，分层是一种设计思想，也可以称之为一种软件架构模式(Pattern)，这种思想的核心在于：划分系统的职责(Responsibility)，如果这个系统的职责你分析清楚了，你的基于设计思路差不多就定下来了。你可以去看看，很多的现在代软件，不是一定是web方面。例如：SVN这样的源代码管理软件、 图一：SVN架构图 .NET Framework也是分层，Eclipse也是，TCP/IP更加是，还有像操作系统（OS）、编译器(Compiler)，很多流行框架(Framework)也是分层。其实，MVC不也是分层，也就是把模型（Model）、视图(View)、控制器（Controller）三个不同职责分开。 那我们看看今天的企业级应用系统（很多说是web项目，其他我不认为是这样，因为web只是一种外在表现形式，我们可以用desktop程序，flash等作为表现形式），企业级应用系统很多人一说就是三层架构，其实确实也是这样的。即：表示层，业务层，数据层。当然还有其他的分层，如：表示层，服务层（服务外观层），业务逻辑层，数据映射层，数据层。也有分成：表现层，中间层，数据访问层等等。(注意这些都是逻辑上分层结构一般用Layer，物理上的分层结构，一般讲的是部署结构一般用tier)总体上都可以看成是三层：表现层，业务逻辑层（也可以说是领域层或领域逻辑层），数据层。像Spring,Structs、ORM 等一些框架，他们都是在不同的层上的相关实现技术。 二、业务逻辑几种实现方式 现在我们再看看，企业级系统中最核心是哪一层？肯定是业务层，因为企业级系统主要是与业务打交道(其实几乎所有软件都是实现业务，企业级系统业务逻辑主要偏向于商业逻辑，其他系统，像游戏，自动化控制、支撑系统等把业务看成是算法)，而且业务是每个系统都不尽相同的。“业务逻辑是最没有逻辑的东西” [Fowler PoEAA,2003]。而且企业级系统的变化与改变大多都在业务层上。那么，做好企业级系统，首先主要分析好业务系统。你可以看看，现今所有的框架在整体结构（spring,structs,等要求系统按MVC结构来开发），表示层(jquery,extjs等)，与数据层(ORM之类）做得最多，有没有业务的框架？（有，但是很少，而且只能是业务比较有规律的地方，像一些财务系统，有些权限系统，当然还有工作流系统）因为业务逻辑每个系统都很可能不一样，没办法通用。那么有什么办法以比较好的方式实现业务逻辑呢。现在终于说到主要问题上来了：也就是业务逻辑(Business Logic)的实现方式，也叫做领域逻辑(Domain Logic)的实现方式。一般来说，有以下几种： 1．事务脚本（Transaction scripts) 2．领域模型（Domain Model) 跟我一起从零开始学WCF(1) 加速企业解决方案部署尽在 Metro – ISV领航计划 收听本次课程需具备的条件 本次课程内容包括 ? 什么是WCF? ? WCF背景介绍 架构设计之分层架构 分层架构的好处：1、它实现了一定程度的关注点分离，利于各层逻辑的重用；2、它规范化了层间的调用关系，可以降低层与层之间的依赖；3、如果层间接口设计合理，则用新的实现来替换原有层次的实现也不是什么难事。 常见模式：展现层、业务层、数据层（三层架构） 一、层的职责 a)展现层，或称为表现层，用于显示数据和接收用户输入的数据，主用户提 供一种交互工操作的界面。 b)业务层，或称为业务逻辑层，用来处理各种功能请求，实现系统的业务功 能，是一个系统最为核心的部分。 c)数据层，或称为数据访问层，主要与数据存储打交道，例如实现对数据库 的增、删、改、查等操作。 二、层间关系 a)展现层会向业务层传递参数，发出服务请求，并获取业务层返回的信息显 示在界面上。 b)业务层接收展现层的命令，解析传递过来的参数，判断各种合法性，并具 体实现功能的各种“运算”要求，返回展现层所要的信息。 c)数据访问层不能被展现层直接调用，而必须由业务层来调用。 例如，《基于动态链接库的复杂信息分层框架设计》一文中用图-1刻画三层架构，体现了层之间的经典调用关系；图-2进一步说明了分层架构下的模块重用。即图中的业务层之“模块2”和数据访问层之“模块2”，都在一定程度上被重用了。 图-1 三层架构示意图-调用关系 图-2三层架构示意图-模块重用 常见模式：UI层、SI层、PD层、DM层（四层架构） 一、UI层，即用户界面层（User Interface），负责封装与用户的双向交互、屏蔽具体交互方式。 二、SI层，即系统交互层（System Interaction），负责封装硬件的具体交互方式，以及封装外部系统的交互。 三、PD层，即问题领域层（Problem Domain），负责问题领域或业务领域的抽象、领域功能的实现。 电子知识 软件架构(4) 1.分层架构：分层架构是使用最多的架构模式，通过分层使各个层的职责更加明确，通过定义的接口使各层之间通讯,上层使用下层提供的服务。分层分为：严格意义上的分层，一般意义的分层。严格意义的分层是n+1层使用n层的服务。而一般意义的分层是上层能够使用它下边所有层的服务。领域驱动设计的分层定义：UI层，UI控制层，服务层，领域层，基础设施层。 2.MVC架构：MVC架构相信做软件的都听说，主要是为了让软件的各部分松耦合，现在好多根据MVC思想构建的框架如：Spring MVC,Structs2,https://www.sodocs.net/doc/c44165632.html, MVC等。MVC是Model View Control的简写，他的原理是什么那，比如拿web来举例吧。当一个web请求来了以后View接收这个请求，随即把请求转发给Control进行处理，Control通过分析请求的类型等信息决定加载哪些Model，当Model加载完成以后Control通知Model已经加载完毕，这是View就去读取Model数据进行显示自己。MVC还有一个衍生架构叫MVP,因为MVC的View跟Control和Model都有耦合关系所以为了解除View和Model之间的关系，View不直接读取Model而是通过Control来转发View 需要的数据。还有一个衍生架构叫MVVP,就是增加了一个ViewControl的层，用来辅助视图的生成，这样View的功能更加简单只是用来显示不包含其它的功能，而且有了ViewControl 使多视图或替换视图很方便。MVP微软的WPF就是使用这种架构。 3.微内核架构：微内核架构就是做一个稳定通用的内核，也就是给软件设计一个强劲的心脏。如果需要更多功能通 基于分层结构的管理信息系统架构设计探 究 引言 管理信息系统(Management Information System ,MIS)是一个由人、计算机及其他外围设备等组成的、能进行信息的收集、传递、存贮、加工、维护和使用的系统。管理信息系统属于是一门新兴的科学, 其主要任务是最大限度地利用现代计算机及网络通讯技术加强企业的信息管理, 通过对企业拥有的人力、物力、财力、设备、技术等资源的调查了解, 建立正确的数据, 加工处理并编制成各种信息资料及时提供给管理人员, 以便进行正确的决策, 不断提高企业的管理水平和经济效益。完善的管理信息系统(MIS)由信源、信宿、信息处理、信息用户和信息管理者五个部分组成。其中信息处理是整个系统的核心, 该部分的主要作用是分离和选择信息、对于信息进行分类与识别、确保信息的准确性与有效性。衡量M IS 的优劣, 主要通过以下标准:需求信息的确定性与有效性、信息的可采集性与可加工性、能否通过程序为管理人员提供有用信息、能否对信息进行有效管理的同时进行分析与判断这四个方面来进行判断。同时, 必须考虑到随着信源、信宿、信息用户和信息管理者的变化, 评价MIS 的标准的具体内容也随之发生变化, 使得信息处理的方法与要求也随之改变,如何在发展中使得现有系统能够最大限度地适应变化, 保持信息处理的准确性与有效性, 一直是MIS 面临的挑战之一。 1 技术发展带来的新挑战 由于MIS 的基础在于最大限度地利用现代计算机及网络通讯技术, 因此MIS 必然是随着现代计算机及网络通讯技术的发展而不断发展的。现有的管理信息系统在为使用单位带来很多的优越性的同时, 也面临了更多新的挑战。概括起来, 目前, 采用的各种管理信息系统, 大都面临以下新的需求: (1)随着M IS 的深入, 各种信息数据共享的需求逐步提高, 同时,M IS 也面临着不断提高的安全要求。 (2)管理对信息数据统一查询、提取、管理的需求,种类日益增加, 数量日益庞大, 要求的速度越来越高。 (3)对经过管理信息系统中的信息数据缺乏集成,难以为管理信息系统内外用户提供全面、详细、快速、准确的信息。 (4)目前管理信息系统主要支持的功能还局限于事后追踪, 还不能够支持如:辅助决策与机器学习等功能。为了能够更好地发挥管理信息系统的功效, 就必须结合技术发展的成果对于信息系统来进行重新思考。 2 现代软件体系结构建模 为了能够充分利用现有的MIS , 同时易于进行功能的扩充, 需要利用技术发展的新成果来进行MIS 架构的重新分析与设计。软件架构理论是近年来研究的热点, 它代表的是面向系统的高层结构指导思想, 是对软件系统结构的总体设计与分析, 对于设计大型复杂的应用系统更具有重要的指导意义。采用软件体系结构的思想来设计架构, 序 序 (1) 前言 (8) 第1章WCF基础 (13) 什么是WCF (14) 服务 (15) 服务的执行边界 (16) WCF与位置透明度 (17) 地址 (18) TCP地址 (19) HTTP地址 (20) IPC地址 (20) MSMQ地址 (20) 对等网地址 (21) 契约 (21) 服务契约（Service Contract） (21) 数据契约（Data Contract） (21) 错误契约（Fault Contract） (22) 消息契约（Message Contract） (22) 服务契约 (22) 应用ServiceContract特性 (25) 名称与命名空间 (28) 托管 (30) IIS托管 (30) 使用Visual Studio 2005 (31) Web.Config文件 (32) 自托管 (32) 使用Visual Studio 2005 (35) 自托管与基地址 (35) 托管的高级特性 (38) ServiceHost 使用绑定 (47) 终结点 (47) 管理方式配置终结点 (48) 绑定配置 (52) 编程方式配置终结点 (53) 绑定配置 (56) 元数据交换 (56) 编程方式启用元数据交换 (59) 元数据交换终结点 (62) 编程方式添加MEX终结点 (64) 简化ServiceHost 分层架构模式:.NET架构和模式 疯狂代码 https://www.sodocs.net/doc/c44165632.html,/ ?:http:/https://www.sodocs.net/doc/c44165632.html,/Programing/Article60049.html 什么是架构 软件Software体系结构通常被称为架构指可以预制和可重构软件Software框架结构架构尚处在发展期对于其定义学术界尚未形成个统意见而区别角度视点也会造成软件Software体系结构区别理解以下是些主流标准观点 ANSI/IEEE 610.12-1990软件Software工程标准词汇对于体系结构定义是:“体系架构是以构件、构件的间关系、构件和环境的间关系为内容某系统基本组织结构以及知道上述内容设计和演化原理(principle)” Mary Shaw和David Garlan认为软件Software体系结构是软件Software设计过程中超越计算中算法设计和数据结构设计个层次体系结构问题包括各个方面组织和全局控制结构通信协议、同步数据存储给设计元素分配特定功能设计元素组织规模和性能在各设计方案的间进行选择Garlan & Shaw模型基本思想是:软件Software体系结构={构件(component),连接件(connector)约束(constrain)}．其中构件可以是组代码如模块；也可以是个独立如数据库服务器连接件可以是过程、管道、远程过程(RPC)等用于表示构件的间相互作用约束般为对象连接时规则或指明构件连接形式和条件例如上层构件可要求下层构件服务反的不行；两对象不得递规地发送消息；代码复制迁移致性约束；什么条件下此种连接无效等 有关架构定义还有很多其他观点比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等虽然各种定义关键架构角度区别研究对象也略有侧重但其核心内容都是软件 Software系统结构其中以Garlan & Shaw模型为代表强调了体系结构基本要素是构件、连接件及其约束(或者连接语义)这些定义大部分是从构造角度来甚至软件Software体系结构而IEEE定义不仅强调了系统基本组成同时强调了体系结构环境即和外界交互 什么是模式 模式(Pattern)概念最早由建筑大师Christopher Alexander于 2十世纪 7十年代提出应用于建筑领域 8十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件Software领域Christopher Alexander将模式分为 3个部分:首先是周境(Context也可以称着上下文),指模式在何种状况下发生作用；其 2是动机( of Forces),意指问题或预期目标；其 3是解决方案(Solution),指平衡各动机或解决所阐述问题个构造或配置(Configuration)他提出模式是表示周境、动机、解决方案 3个方面关系个规则每个模式描述了个在某种周境下不断重复发生问题以及该问题解决方案核心所在模式即是个事物(thing)又是个过程(process)不仅描述该事物本身而且提出了通过怎样过程来产生该事物这定义已被软件Software界广为接受 软件Software模式应用对软件Software开发产生了重大作用主要表现在: 软件Software模式是人们在长期设计软件Software、管理组织软件Software开发等实战中大量经验提炼和抽象是复用软件Software设计思路方法、过程管理经验有力工具模式类似于拳击中组合拳它提供了系列软件Software开发中思维套路如通过模式使用有利于在复杂系统中产生简洁、精巧设计 8.2Hello, World实例 本实例与传统入门教材相同，仍然以输出一个“Hello，World”字符串开始。实例将新建2个项目，第一个项目名为“HelloWorldService”，它提供WCF服务，并且以开发环境方式暴露一个端口供客户端调用；另外一个项目叫“HelloWorldClient”，它调用WCF服务方法，并输出返回值。 本实例的运行结果如图所示： 8.2.1创建WCF服务端程序 1）打开Microsoft Visual Studio 2010； 2）选择菜单>文件>新建>项目； 3）在弹出的“新建项目”对话框中展开左边的“已安装的模板”>Visual C#； 4）选择“WCF”； 5）在对话框右边选择“WCF Service Application“； 6）在对话框下部的“项目名“中输入”HelloWorldService“，在位置中输入” d:\Exercise “，在解决方案名称输入”WcfSample“，确保选中”Create directory for solution “，确保未选中”Add to source control“，设置后的界面如下： 7）点击“OK“按钮，VS2010已自动建立了一个WCF Service Application，并且为我们自动打开了Service1.svc.cs文件； 8）打开“Solution Explorer”；（VS2010默认打开，位置在VS2010桌面的右边，如果VS2010没有打开，请使用快捷键Ctrl + W，S打开） 9）在“Solution Explorer”中展开“HelloWorldService”； 10）双击“IService1.cs”文件； 11）用下面的代码 /// 物理结构设计： --创建卡类型表 create table会员卡(类型编号int primary key, 类型名char(10), 有效天数char(10), 价格money ); --创建机械表 create table机械(机械编号int primary key, 机械名称char(10), 使用介绍ntext ); --创建管理员表 create table管理员(管理员编号int primary key, 姓名char(10), 登录密码nvarchar(10), ); --创建教练表 create table教练(教练编号int primary key, 姓名char(10), 性别char(4), 年龄char(3), 电话号码nvarchar(20), 登录密码nvarchar(10), Constraint c1 check(性别in('男','女')) ); --创建课程表 create table课程(课程号int primary key, 课程名char(10), 课程简介ntext,, 机械编号int, constraint s1 foreign key(机械编号)references机械(机械编号) ); --创建活动表 create table活动(活动编号int primary key, 活动主题char(20), 活动内容ntext, 活动时间timestamp, 活动地点char(20), 组织者char(10) ); --创建分店表 create table分店(分店编号int primary key, 分店名称char(20), 软件架构设计三篇 篇一：软件架构设计之常用架构模式 1.分层架构：分层架构是使用最多的架构模式，通过分层使各个层的职责更加明确，通过定义的接口使各层之间通讯,上层使用下层提供的服务。分层分为：严格意义上的分层，一般意义的分层。严格意义的分层是n+1层使用n层的服务。而一般意义的分层是上层能够使用它下边所有层的服务。领域驱动设计的分层定义：UI层，UI控制层，服务层，领域层，基础设施层。 2.MVC架构：MVC架构相信做软件的都听说，主要是为了让软件的各部分松耦合，现在好多根据MVC思想构建的框架如：Spring MVC,Structs2,https://www.sodocs.net/doc/c44165632.html, MVC等。MVC是Model View Control的简写，他的原理是什么那，比如拿web来举例吧。当一个web请求来了以后View接收这个请求，随即把请求转发给Control进行处理，Control通过分析请求的类型等信息决定加载哪些Model，当Model加载完成以后Control通知Model已经加载完毕，这是View就去读取Model数据进行显示自己。MVC还有一个衍生架构叫MVP,因为MVC的View跟Control和Model 都有耦合关系所以为了解除View和Model之间的关系，View不直接读取Model 而是通过Control来转发View需要的数据。还有一个衍生架构叫MVVP,就是增加了一个View Control的层，用来辅助视图的生成，这样View的功能更加简单只是用来显示不包含其它的功能，而且有了View Control使多视图或替换视图很方便。MVP微软的WPF就是使用这种架构。 3.微内核架构：微内核架构就是做一个稳定通用的内核，也就是给软件设计一个 七步通使用WCF Service流程 Service对于编程人来说并不陌生，学习了很长时间的WCF，我们现在就WCF Service 一起来和大家分析探讨一下。熟悉Web Service开发的程序员对添加服务引用应该并不陌生。在创建某个服务的客户端程序时，并不需要从头开始编写客户端的底层通信和交互代码，可以通过输入服务地址来添加服务来让Visual Studio生成客户端代理，这样访问服务就像访问本地组件一样，而不需要去关心通信的细节。 如果创建的客户端程序项目和服务程序项目处在同一个解决方案里（很多开发者在开发服务时，也会同步开发客户端程序），还可以通过Visual Studio来帮助我们“发现（Discovery）”服务，并添加服务引用。现在开发WCF Service的程序员也可以得益于这些功能了。如果从WCF Service Library (或者WCF 节点下的Sequential Workflow Service Library 和 State Machine Workflow) 项目模板创建一个项目，那么这些功能就已经具备。 下面我们来看一下如何使用： 1.创建一个客户端程序，可以是一个Windows Console程序。 2.在同一解决方案里添加一个WCF Service Library。如图： 3.Build WcfServiceLibrary1。 4.右键ConsoleApplication1，在上下文菜单中选择“添加服务引用“(Add Service Reference). 5.此时可以看到一个对话框: 6.如果已经知道服务的地址，可以直接在Address栏输入地址来添加服务，单击“Go”。可以找到这个地址对应的服务。 7.如果想添加同一个解决方案里的服务，可以先单击“发现”来寻找服务。找到服务后，选中需要在客户端程序生成引用的服务，然后单击确定，这个时候WcfSvcHost就会自动启动来HOST服务。几秒以后，可以看到客户端自动生成了服务代理代码： 通过上面的步骤在客户端完成了添加服务引用，现在可以访问服务了，只需要通过下面两行代码就可以调用服务端的一个方法： 1.ServiceReference1.Service1Client client = new ServiceReference1.Serv ice1Client(); 2.client.GetData(0); Win7下使用IIS托管WCF服务 第一步，确保Win7正确安装了IIS。 操作步骤： 1.打开控制面板-程序和功能-点击左侧“打开或关闭Windows功能”，在弹出框中选中 “Internet信息服务”，需要注意的是有的需要将其展开，选中相关项。 2.在浏览器中输入http://localhost，如果出现了IIS启动界面，即表示IIS安装成功。 第二步，在进行IIS托管WCF服务之前，先建立一个https://www.sodocs.net/doc/c44165632.html,程序试下。 由于Win7+VS2010使用的是.Net 4.0，所以需要确保注册了https://www.sodocs.net/doc/c44165632.html, 4.0。 操作步骤： 1.进入C:\Windows\System32找到cmd.exe，右键“以管理员身份运行”，然后在控制台输 入：cd C:\Windows\https://www.sodocs.net/doc/c44165632.html,\Framework\v4.0.30319切换到该目录 2.然后输入：aspnet_regiis.exe –i，就会看到正在注册，以及注册成功的提示信息。 备注：最好使用控制台来进行https://www.sodocs.net/doc/c44165632.html,的注册，其实也可以直接以管理员身份运行aspnet_regiis.exe，但是会看不到是否成功的提示！ 第三步：创建解决方案，并发布https://www.sodocs.net/doc/c44165632.html,网站 操作步骤： 1.创建一个默认的https://www.sodocs.net/doc/c44165632.html,网站，不用更改其中任何东西。 2.在项目上，右键“属性页”，在“启动选项”中的“特定页”和服务器，进行如下设置： 需要注意的是，这时如果你在项目上右键-在浏览器中查看，会发现不能访问。 3.鼠标右键-发布网站，出现如下图所示对话框： 点击“目标位置”进入如图对话框： 选择“文件系统”，即表示你要将你的网站发布到的本地计算机的位置，在第四步建立网站的时候会引用。 备注：由于，我们没有修改代码，应该发布会很顺利。 系统架构分层设计 本文讨论关于项目系统架构的拆分模型，阐述每个层次（layer）的作用，以及面向SOA编程提供服务的方式。 服务端架构解决之道 大家看到这张图，用了一个形象的比喻来体现传统的服务端软件。最下层是操作系统，通常是Linux，最上层是我们的业务功能和服务。在服务端架构，很习惯用增加一个架构层次的方式来解决问题。例如缓存层、数据访问层。在架构上按照自己的意愿去搭建不同层次的衔接环节，使架构具有足够的灵活性和扩展性。即时堆成这样，它依旧是非常合理的。 MVC Framkwrok # Model与Controller通信 Model与Controller之间是用实线表示，这表明Model并不能随意的访问Controller，但是有时Controller是需要接收Model层的消息的。在MVC模式中，要实现Model层到Controller层的通信，使用了一种类似广播的方式。Model中数据变化时，Model会发出一条广播，然后对这个Model感兴趣的Controller就会收到广播并告诉对应View改变现实方式。 MVC中的Controller，即控制器，控制着整个程序的逻辑和Model如何显示到View层。Controller把Model和View连接起来，让我们可以在View上看到Controller想要Model层现实的样子。 # View与Controller通信 在程序过程中，View层其实是需要与Controller通信的，当然View层不可能直接调用Controller的某个方法来处理用户点击事件，因为View不知道该使用Controller中的哪个方法。因此，使用了一种叫做Target的方式来处理这个问题，Controller会事先告诉View，如果触发了某个事件，View就会把这个动作转给Target。然后Controller运行完该方法，处理好这个时间以后就会告诉Veiw。 作者: 风尘浪子来源: 博客园发布时间: 2011-04-12 11:07 阅读: 3121 次原文链接全屏阅读 [收藏] SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是service）组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。使用WCF实现SOA，正好可以利用WCF的灵活性，把业务层封装，发布为Web服务。这样可以降低系统的耦合度，加大对未知业务的扩展性。 Web服务本来就是没有区分代码的，在这个例子里在下多开发了一个Service Interface目的是为了使系统更易于管理。在开发期间，Service是不断更改的，如果在UI层上直接调用服务层，那更改将会是频密的，所以在这里在下开发一个Service Interface层目的是为了把WSDL集成在同一个DLL程序集里面，进行统一修改。最后UI层只要直接调用Service Interface，就可以对系统直接进行操作。要以不同开发工具来实现Service Interface，这个的代价并不大，开销是可以承担的。下面附上最简单的例子，希望有经验的高手给予点评，有不妥的地方请多加指教。 本文和大家讲下WCF服务如何获取客户端在线用户数量？你没有关注过这个问题吧，一起来看下本文的实现方法。【1】问题分析: 这个问题，在WCF服务编程中也非常的常见，以下是对于这个问题的不同描述形式，但是本质基本类似：WCF如何获取在线客户端数量？ WCF如何获取在线用户列表？ WCF服务如何知道客户端离线？ 如何判断WCF离线客户端？ 或许还有别的提法，但是基本都是差不多的。 此类问题出现在回调、双工通信的场景中比较多，有的程序具备类似聊天室的功能，就比较在乎客户端的离线事件。 【2】解决办法: 这里服务端对于客户端在线的判断，也是固定的，基本是基于对通道状态的判断，来实现对于客户端在线状态的判断。 实现的思路基本就是，在服务端维护一个在线客户端Channel的列表List，然后每次通道关闭（Closed）或者出错（Faulted）调用特定的方法来移调通道。 这里另外一个需要注意的地方就是多线程并发的问题。 因为在线用户通道list是一个静态变量，多线程访问的时候，需要注意互斥操作的问题。 【3】示例代码： 这里的代码页比较简单，基本思路： //回调通道列表，也可以用来保持 private static List 使用VS自带的WCFSVCHost(WCF服务主机)发布WCF服务，时刻开发人员测试使用。下面我们来看一下如何在IIS中部发布一个WCF服务。 环境是VS 2008 （公司电脑没有安装VS2010）^_^ 我们从头开始，不写代码，完全的配置，会收获不小。 新建一个WCF 服务库 建立一个WCF服务应用程序 结果如下 删除掉WCF程序中不需要的默认文件，如下图 为WcfService1项目添加WcfServiceLibrary1的引用，如下图。 修改声明指示内容，让这个Service.svc文件的后台代码指向我们创建的WCF服务库项目--WcfServiceLibrary1项目中的服务类，改后的代码如下： <%@ ServiceHost Language="C#" Debug="true" Service="WcfServiceLibrary1.Service1" %> Ctrl+Shift+B 编译一下解决方案，配置工具用的反射，先编译才行 此时我们的WCF服务站点并不能把WCF服务库中的服务和终结点发布出来，还需要我们对web.config进行一系列的配置工作。 右键我们要配置的Web.Config文件,编辑WCF配置 在弹出的服务配置窗口中，把Service1服务指定到WCF服务库的WcfServiceLibrary1.dll 中的WcfServiceLibrary1.Service1服务类上。 再把其中的一个对外终结点的Contract设为WCF服务库的WcfServiceLibrary1.dll中的WcfServiceLibrary1.IService1服务契约上。 一、开发环境 操作系统：Windows 7 开发环境：VS2013 编程语言：C# IIS版本：10.0.0.0 二、添加WCF服务、Internet Information Services(IIS) 1、进入“控制面板”，打开“程序和功能”，点击左上角的“启用或关闭Windows功能”后，在“.NET Framework 4.6 高级服务”中的子节点选中“WCF 服务”，如下图所示： 2、再找到“Internet Information Services”，同样选中该节点，如下图所示： 3、点击“确定”按钮以便安装这些服务与组件，等待完成安装即可。 三、新建一个WCF服务库 1、使用VS2015新建一个WCF服务库，并将项目名称改为“MyWCFService”，如下图所示： 3、将鼠标移到解决方案资源管理器中项目“MyWCFService”上并右击鼠标，弹出上下文菜单，在菜单中选中“发布”后，弹出下图所示的“发布WCF服务”对话框，如下图所示： 在目标位置选择“D:\WCF”，其他按默认，点击“发布”按钮，即可在“D:\WCF”文件夹里生成 如下图所示的文件： 四、新建一个WCF服务网站 1、打开控制面板-管理工具 2.点击打开IIS，右键点击网站，新建一个网站，网站名称设置为“MyWCFService”，物理地址选择“D:\WCF”，端口从默认的80改为81，如下图所示： 3点击确定后，即新建一个WCF服务网站。 五、服务器程序编辑（编辑完成后需要再次发布） 1、点击解决方案下的server1.Cs—GeteData 2、在此处添加程序 六、创建客户端 1、新建一个Windows窗口客户端 2、在解决方案下的引用点击右键，添加服务器引用 WCF客户端动态设置WCF服务器主机的地址的方法参考，可以连接多个相同WCF主机的方法 最近做一个项目，需要在客户端灵活配置连接到哪个服务器的功能，例如客户端是一个，现在想连接A服务器就连A服务器，想连接B服务器就连接B服务器，当然不需要手动修改配置文件，直接通过程序来实现WCF目标主机的配置功能。 参考核心代码如下： //-------------------------------------------------------------------- // All Rights Reserved , Copyright (C) 2011 , Hairihan TECH, Ltd. //-------------------------------------------------------------------- using System.ServiceModel; namespace DotNet.WCFClient { using DotNet.IService; using DotNet.Utilities; /// ///修改纪录 /// /// 2011.07.03 版本：2.0 JiRiGaLa 可以动态指定服务器地址的调用方法。 /// 2009.09.20 版本：1.0 JiRiGaLa 创建。 /// ///版本：2.0 /// /// 分层软件架构设计及其应用研究 摘要：在当前软件系统设计中，使用多层架构设计能很好地实现系统功能的分离。本文分析了多层架构的利弊以及分层架构设计基本原则，并通过架构图描述了三层架构中各层的职责以及实现细节，很好地说明了层次之间交互关系。关键词：分层架构；三层架构；依赖倒置；接口 1．引言 分层的本质是什么？了解分层的本质，就得理解分工的概念。分工是劳动生产力上最大的改良，由于各司其职，每个人可以从事其最擅长的劳动，再加上单纯劳动所带来的劳动熟练度提升和减少了更换劳动时的损失，使得劳动生产率大幅提升。 分层描述的是这样一种架构设计过程：从最低级别的抽象开始，称为第1层。这是系统的基础，通过将第K层放置在第K-1层的上面逐步向上完成抽象阶梯，直到到达功能的最高级别，称为第N层。 因而分层架构就可以定义为：将系统的组件分隔到不同的层中，每一层中的组件应保持内聚性，并且应大致在同一抽象级别；每一层都应与它下面的各层保持松散耦合。2．典型的三层架构 典型三层架构即将系统分为三层，分别是数据访问层(DAL)、业务逻辑层(BLL)和表示层(UI)。 数据访问层实现对数据库操作的封装，完成数据的存储与读取，即针对数据的增添、删除、修改、更新、查找等操作； 业务逻辑层则实现对业务逻辑的封装，隔离用户操作的界面和具体业务逻辑；它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计。它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。 表示层即用户界面层，为用户提供一种交互操作的界面。 3．分层架构的利弊分析 分层架构的优点： （1）开发人员的专业分工，专注理解某一层。由于某一层仅仅调用其相邻下一层所提供的程序接口，只需要本层的接口和相邻下一层的接口定义清晰完整，开发人员在开发某一层时就可以像关注集中于这一层所用的功能和技术。 （2）可以很容易用新的实现来替换原有层次的实现。只要前后提供的服务（接口）相同，即可替换。系统开发过程中，功能需求不断变化，我们可以替换现有的层次以满足新的需求变化。 （3）降低了系统间的依赖。比如业务逻辑层中的业务发生变化，其他两层即表现层以及数据访问层程序也不需要变化。这大大降低了系统各层之间的依赖。 （4）有利于复用。充分利用现有的功能程序组件，将已经辨识的具有相对独立功能的层应用于新系统的开发，保证新系统开发的过程中，能够将重点集中于辨识和实现应用系统特有的业务功能，最终缩短系统开发周期，提高系统的质量。 分层架构的弊端 （1）级联修改问题。一些复杂的业务中，由于业务流程发生变化，为了这个变化所有层都需要修改。 （2）性能问题。本来是直接简单的操作，现在需要在整个系统中层层传递，势必造成性能的下降，同时也加大的开发的复杂度。 从上面的分析可以看出，分层架构设计有许多优点同样存在不足，在实际使用过程中，我们应该权衡利弊关系，选择一种符合实际项目的最佳方案。 4．分层架构设计的基本原则 针对分层架构的特点，结合常用的设计方法简单描述一些在分层架构设计中的一些基本原则。 4.1 单一职责原则 在面向对象程序架构设计中，任何一个操作类都应该有单一的职责，属于单独的一层，而不能同时担负两种职责或属于多个层次，比如实体类及辅助类可以被多个层使用，但它们不属于任何一个层，而是独立存在，这也能增强系统层次的内聚。 4.2 开放-关闭原则 开发-关闭原则定义为：对扩展开放，对修改关闭。 具体到分层架构中，可以描述为：当某一层有了一个新的具体实现时，它应该可以在不修改其他层的情况下，与此新实现无缝连接，顺利交互，降低了系统层次间的依赖。4.3 依赖倒置原则 在软件设计原则中，有一种重要的原则叫依赖倒置。它的核心思想是：高层组件不能依赖底层组件，低层组件也不能依赖于高层组件，两者都应依赖于抽象。这里说的“依赖”是指“抽象层”。 抽象层包含的应该是应用系统的抽象逻辑，通过对整个系统的需求分析把那一些最稳定的、最有必要的元素抽象出来，把这层将来会改变的可能性降低到最低。具体层次的跟具体业务相关代码是经常变动的，这样更能体现良好的可扩展性以及开封原则。 4.4 针对接口编程，而不是针对实现编程 这里所指的接口，是指一种抽象的，在语义层面上起着接合作用语义体。它的具体实现，可能是接口，可能是抽象类，甚至可能是具体类。 具体到N层架构中，针对接口编程的意义在部分上是分层架构与业务逻辑实现方式
WCF教程(一)
WCF概述
徐长龙 MSDN 特邀讲师 vsts_china@https://www.sodocs.net/doc/c44165632.html,
资源和利益
? 用于解决方案开发的集中资源 用于解决方案开发的集中资源：资源包括指向测试工具、开发 资源包括指向测试工具 开发 人员 SDK、技术论坛、联机培训等的链接，微软全球技术支持 中心( (GTSC) )的邮件技术支持。 ? 对市场调查的访问权限：您可以使用这些宝贵信息来识别您当 前的客户或未来客户的特定需求。 ? 认证徽标计划：该徽标可以向客户证明您所具有的优秀技术。 ? 市场营销和销售支持
https://www.sodocs.net/doc/c44165632.html, h O
最先应用微软最新技术 提升ISV 提升 ISV竞争优势和商业价值 竞争优势和商业价值
? Metro 提供了结构化的支持来帮助ISV进行新技术的评估和 部署 部署： Discover – 参与前沿技术培训 – 评估最新的微软技术及产品 Release Learn – 获取微软Beta版产品的技术支持 – 联络全球开发人员和架构师社区 – 与世界级的商务和技术社区分享最先 Develop 部署的经验
? 熟悉Web Service编程 ? 熟悉Visual Studio 2005/2008 ? 熟悉分布式应用程序开发
Level 200架构设计之分层架构
软件架构设计之通用架构模式
基于分层结构的管理信息系统架构设计探究
WCF服务编程
分层架构模式.NET架构和模式
WCF实例
物理结构设计
软件架构设计三篇
七步通使用WCF Service流程
Win7下使用IIS托管WCF服务
系统架构分层设计
使用WCF实现SOA面向服务编程
WCF服务如何获取客户端在线用户
一个完整的WCF服务的发布与测试过程
wcf服务器和客户端创建
WCF客户端动态设置WCF服务器主机
分层软件架构设计及其应用研究