51CTO博客开发小王的博客
ASP.NET由于采用了管道式设计，具有很好的扩展性，而整个ASP.NET MVC应用框架就是通过扩展ASP.NET实现的。通过上面对ASP.NET管道设计的介绍，我们知道ASP.NET的扩展点只要体现在HttpMoudle和HttpHandler这两个核心组建之上，实际上整个ASP.NET MVC框架就是通过自定义的HttpMoudle（UrlRoutingModule）和HttpHandler（MvcHandler）实现的。为了上读者从整体上把握ASP.NET MVC的工作机制，接下来我按照其原理通过一些自定义组件来模拟ASP.NET MVC的运行原理，我们也可以将此视为一个“迷你版”的ASP.NET MVC。值得一提的是，为了让读者根据该实例从真正的ASP.NET MVC中找到对应的组件，我完全采用了与ASP.NET MVC一致的类型命名方式。[源代码从这里下载]
[上篇]通过采用MVC模式，我们可以将可视化UI元素的呈现、UI处理逻辑和业务逻辑分别定义在View、Controller和Model中，但是对于三者之间的交互，MVC并没有进行严格的限制。最为典型的就是允许View和Model绕开Controller进行直接交互，View不仅仅可以通过调用Model获取需要呈现给用户的数据，Model也可以直接通知View让其感知到状态的变化。当真正地将MVC应用于具体的项目开发中，不论是基于GUI的桌面应用还是基于Web UI的Web应用，如果不对Model、View和Controller之间的交互进行更为严格的限制，我们编写的程序可以比自治视图更为难以维护。
对于大部分面向最终用户的应用来说，它们都需要具有一个可视化的UI与用户进行交互，我们将这个UI称为视图（View）。在早期，我们倾向于将所有与视图相关的逻辑糅合在一起，这些逻辑包括数据的呈现、用户操作的捕捉与相应以及和针对数据存储（比如数据库）的操作。我们将这种设计模式称为自治视图（AV，Autonomous View）。 目录 一、自治视图 二、MVC模式
ASP.NET MVC是一个全新的Web应用框架。将术语ASP.NET MVC拆分开来，即ASP.NET+MVC。前者代表支撑该应用框架的技术平台，意味着ASP.NET MVC和传统的Web Forms应用框架一样都是建立在ASP.NET平台之上。后者则表示该框架背后的设计思想，意味着ASP.NET MVC采用了MVC架构模式。
不知道大家是否意识到一个现象，我们所说的Web服务其实并没有直接建立在Web上而是建立在SOAP上。SOAP居然成为了Web服务的标准，以至于我们提到Web服务就会想到SOAP。随着在Web服务中引入了REST架构，SOAP在整个Web服务体系中的垄断地位正在发生改变，或者已经发生了改变。REST提倡一种面向资源的架构（ROA: Resource Oriented Architecture），鼓励我们直接在Web上建立一种轻量级的Web服务。WCF在3.5就提供了对REST的支持，在4.0中对此进行较大的改进。在这章中我们不仅仅为介绍WCF 基于REST的编程模型，还会从WCF运行时框架的角度剖析REST服务在WCF中是如何实现的。
作为.NET Framework的一部分，几乎每个版本.NET Framework的推出都会为WCF带来一些改变。针对于最新版本的.NET Framework 4.0，一些新的特性被引入到WCF。对于这些基于.NET Framework版本的更替而带来的针对WCF的变化，我个人是这么看待的：WCF在随着.NET Framework 3.0发布的时候就具有一个成熟的架构设计，可扩展性即使一个重要的衡量标准。基于后续版本的.NET Framework发布的WCF并没有像WF一样出现“革新”型的改变，很多都是利用了这个可扩展性的通信平台开发出来的新特性，WCF 4.0也不例外
整个WCF框架由两个基本的层次构成，即服务模型层和信道层。对信道层的扩展主要通过针对绑定的扩展实现，具体来说就是自定义绑定元素，以及相关的信道管理器（信道监听器和信道工厂）、信道来改变对消息的处理和传输方式。 而对于服务模式型层的扩展则主要体现服务端和客户端运行时框架的定制，进而让WCF按照我们希望的方式进行运作。由于整个运行时框架由一系列的可扩展组件构成，并且大部分运行时属性也可以改写，所以针对服务模型层的扩展具体体现在：根据具体的需要定义相应的组件，并以某种情形将这些自定义的组件应用到运行时框架相应的地方，或者按照我们希望的方式定制相应的运行时属性。
在安全领域，认证和授权是两个重要的主题。认证是安全体系的第一道屏障，守护着整个应用或者服务的第一道大门。当访问者叩门请求进入的时候，认证体系通过验证对方提供凭证确定其真实身份。作为看门人的认证体系，只有在证实了访问者的真实身份的情况下才会为其打开城门，否则将之举之门外。 当访问者入门之后，并不意味着它可以为所欲为。为了让适合的人干适合的事，就需要授权机制为具体的人设置具体的权限，并根据这些权限设置决定试图调用的操作或者访问的资源对该访问者是否是安全的。对于一个安全保障体系来说，授权是目的。
前一阵子写了不少关于代码生成相关的文章，介绍了一些如何通过VS自动生成代码的解决方案，比如CodeDOM、T4以及ASP.NET的BuildProvider等。现在将它们作一个汇总，给广大读者作一个参考。
Enterprise Library是微软P&P部门开发的众多Open source框架中的一个，最新的版本已经出到了4.1。由于接触Enterprise Library已经有很长的一段时间，在实际的项目中使用的频率也很高。对此有了一些积累，希望通过这个新的系列和广大网友一起分享和交流。本系列假设读者已经对Enterprise Library有一定的了解，故而不会对各个Application Block的基本原理和编程模型进行介绍，而把侧重点放在Enterprise Library深层次的实现原理、设计模式的应用、有效扩展和最佳实践上。
作为一个通信基础平台,WCF必须保证通信的可靠性。由于消息交换是WCF采用的通信手段，通信可靠性的保障体现在确保消息的可靠传输。WCF本质上是一个消息处理框架，作为整个消息交换系统的两个终端，即发送端和接收端。换句话说，WCF仅仅负责对消息的发送和接收，一旦消息通过WCF的信道层进入了网络，就脱离了WCF的控制范围。但是，由于网络环境的限制，网络层不能百分之百地确保对消息的有效交付。如何克服中间环节的制约，确保从一端发送的消息能够被有效地交付给另一端，这就是可靠消息传输（Reliable Messaging）需要解决的问题。WCF通过可靠会话（Reliable Sessions）实现了种种端到端（End to End）的可靠消息传输。
服务（Service）的本质就是提供服务消费者期望的某种功能，服务的价值体现在两个方面：服务本身的质量和寄宿服务的平台应付消费者的数量，并发（Concurrency）的关注的是第二个要素。WCF服务寄宿于资源有限的环境中，要实现服务效用的最大化，需要考虑如何利用现有的资源实现最大的吞吐量（Throughput）。提高吞吐量就某个寄宿的服务实例（Service Instance）来说，一个重要的途径就是让它能够同时处理来自各个客户端（服务代理）的并发访问。WCF实现了一套完整的并发控制体系，为你提供了不同的并发模式。
在一个基于SOA架构的分布式系统体系中，服务（Service）成为了基本的功能提供单元，无论与业务流程无关的基础功能，还是具体的业务逻辑，均实现在相应的服务之中。服务对外提供统一的接口，服务之间采用标准的通信方式进行交互，各个单一的服务精又有效的组合、编排成为一个有机的整体。在这样一个分布式系统中某个活动（Activity）的实现往往需要跨越单个服务的边界，如何协调多个服务之间的关系使之为活动功能的实现服务，涉及到SOA一个重要的课题：服务协作（Service Coordination）。而具体来讲，一个分布式的活动可能会执行几秒钟，比如银行转帐；也可能执行几分钟、几个小时、几天甚至更长，比如移民局处理移民的申请。事务，无疑是属于短暂运行服务协作（Short-Running Service Coordination）的范畴
从整个基础构架的层次结构上讲，WCF可以分成两个部分：服务模型层（Service Mode Layer）和信道层（Channel Layer）。服务模型层建立在信道层之上，提供了一个统一的、可扩展的编程模型。信道层则通过绑定（Binding）建创的信道栈为消息通信提供了一个传输、处理的通道。
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
