• 远程服务调用
• 离线处理
• 事件
• 缓存

建议按顺序下载观看（需要音箱）

想要了解Agile Framework的更多信息请点击这里

增加了Agile Framework的详细介绍，源码也即将发布。

(既然发在首页，按照园子里的规定应该多一些内容的。本来想直接把介绍贴过来，不过无奈原来是用WORD写的，贴过来之后格式完全都变了，调整了半天后只好放弃，大家还是直接去专区看吧）

但是由于这个模型在Web Service模式下是采用的轮询机制，这种机制会产生这样的问题：

1. 性能问题。每个客户端都频繁的轮询服务器，在工作站比较多的情况下会给服务器的负载带来巨大的压力。
2. 响应延迟。在这种事件分发机制下。事件的响应时延取决于轮询的频率，轮询频率越高则延迟越小，而频率越低则延迟越大。

这两个问题互相矛盾：为了提高事件的响应速度，就必须提高轮询频率；而提高了轮询频率又会加大服务器的负载。所以造成了事件响应速度和服务器负载两者不可兼得的局面。

为了解决这个问题，AF改良了事件分发机制，将事件探测器移到服务器端，结构如下图所示：

从结构上来看，没有太大的变化，主要的改变是将事件探测器从客户端移动到了服务器端。客户端照样也轮询事件，但是如果没有事件，服务器的这个线程就进入睡眠状态，不让它返回。同时该线程每隔一定时间就醒来检查一下有没有事件发生。如果有事件就马上返回。

因为这种轮询不占用网络资源，所以可以将服务器的轮询间隔时间设置得很短（目前默认值是100ms）。同时因为服务器Hold了线程，所以客户端的事件轮询也可以设置得很短，甚至可以无延迟。

这样一来，由于是服务器内部的线程处理，并且获取事件的操作代价并不高，所以这个事件探测器大部分时间都会是在休眠状态，因此服务器并没有被消耗多少资源。同时由于轮询不需要远程传递结果，因此可以将轮询时间设置得非常短，因此也极大的提高了事件的响应速度（原来的事件的最长响应时间是1s，现在是100ms，提高了十倍）。

另外，为了防止客户端意外的中断和请求超时，可以设置一个最长轮询次数。假如超过了最长轮询次数，服务器线程也返回，假如客户端仍然是活跃的，它马上会发出一个新的获取事件请求。然后服务器又开始进入新的轮询。

Agile Framework目前主要包含两个部分：客户端部分和服务器部分。在服务器端，AF的采用了Castle作为核心的的IoC容器，由于采用了这种轻量级容器技术，使得AF可以很容易的支持“POJO”业务对象（这是Java里面的说法，不知道在.Net里面同样的意思应该怎么叫）。而在客户端，AF采用的是Composite UI Application Block，它是一个结构非常酷的SmartClient框架，而且本身也带有一个IoC容器。由于采用了CAB技术，使AF拥有了非常强大灵活的界面插件能力。

Caslte拥有一个非常强大的IoC核心以及MonoRails Web框架和ActiveRecord数据框架，但是缺少一个强大的SmartClient客户端。而CAB有很强大的客户端框架，却没有相应的服务器部分。在一个企业应用架构中，往往需要同时构建服务器端和客户端应用，假如单独的使用它们的话会非常麻烦。

AF对这两个容器框架都做了许多额外的扩展工作，把它们包装起来，使得这两个框架无缝的融合为一体。同时在这个基础之上做了许多对构件企业应用程序非常有帮助的服务集成和扩展。

这幅图表述了Agile Framework的基本模块结构和开发模式，Agile Framework提供了通明的分布式计算能力，客户端组件和服务器端组件实际上虽然处于不同的容器之中，但是对组件来说，Agile Framework提供了几乎完全相同的容器模型，客户端组件访问服务器端服务就好像访问本地容器中的服务一样。

开发人员在Agile Framework框架上编写应用程序，目前可以获得如下好处：

• 分布式容器。只需要编写客户端界面控件和服务器端的业务逻辑组件，并“插入”到框架之中就可以。由框架提供依赖注入能力。并且依赖关系可以是分布式的，比如你可以在客户端插件中声明一个服务器端组件的依赖请求。
• 分布式事件。无论是服务器端还是客户端组件，只要是放到Agile Framework中，所有的组件都获得了完整的通信能力，除了可以请求组件的服务外，还可以互相之间订阅事件。并且事件是完全解耦的，并不需要显式的挂接事件，只需要声明一下事件发送者和订阅者的标记，Agile Framework会自动的连接有对应关系的事件。同样，事件也是分布式的，你可以在客户端组件中订阅服务器端的事件。
• 透明的底层传输机制。目前在Agile Framework中同时支持两种数据传输方式：Web Service和Remoting。你可以根据实际使用环境的需要灵活的配置。你可以在Intranet中将传输方式配置成Remoting，提高性能。或者将传输方式配置成Web Service，以满足通过企业防火墙的需要。而这一切对组件来说都是透明的，完全不用关心底层具体的传输方式。甚至你可以配置成“自动检测”，框架首先尝试采用Remoting，如果不能用Remoting就自动切换成Web Service。
• 自动离线处理机制。不需要再去编写复杂的离线处理任务，Agile Framework已经提供了一套完善的离线处理机制，采用Agile Framework编写的应用程序可以非常轻易的拥有离线处理功能。让你的应用程序拥有非常好客户体验。
• 常用服务和类库。与Castle和CAB不一样，Agile Framework是一个企业应用开发框架，所以内置了许多帮助开发企业级应用程序的服务和类库，比如日志服务、事务服务、工作流服务、缓存服务、安全认证服务、异常管理服务等等。此外还提供了大量的非常有用的帮助类库（Helper），比如单位转换、动态排序、表达式计算、日期转换、加密压缩、文件操作等等在企业开发中会频频使用到的基础功能。

对Agile Framework的结构总体概览就介绍到这里，以后会详细的介绍Agile Framwork的一些内部技术细节以及框架所提供的各种服务和Helper类的功能介绍和使用方法。

Agile Framework是一个基于.Net 2.0技术的开源企业开发框架，目前Agilelabs Team正在加紧开发中，期望能尽早的放出第一个版本。希望了解更多信息请访问敏捷实验室。

在Agile Framework中，只要为组件分别标记上EventPublisher和EventSubscriber就可以自动实现互相之间的连接，实现了事件的完全解耦。这个功能和Castle容器的EventWiringFacility的功能很像（在Composite UI Application Block中也有同样的事件机制）。但是和它们不同的是，Castle和CAB都只支持同一个容器内的事件互相连接。而Agile Framework的容器是分布式的，客户端组件和服务器组件都可以被加入到容器中，因此，Agile Framework的事件传递机制也是分布式的。简单的说，在服务器的业务组件中定义的事件也可以被客户端的组件接收到。

为了实现这个功能首先需要解决一个难题：因为Agile Framework可以同时支持Web Service和Remoting数据传输接口（只需要在配置文件中简单的修改一下配置，框架采用什么类型的传输接口对开发人员来说是完全透明的），所以就必须让事件传递机制同时支持这两种接口。用Remoting还比较好解决，因为Remoting本身就支持远程的事件机制。但是Web Service就麻烦了，它只支持简单请求/响应的无状态访问模型，无法主动让服务器发消息给客户端。

Agile Framework采用的Event Dispatch机制比较完美的解决了这个问题，以下是框架的事件模型图：

在整个结构中，Event Dispather是所有事件的中转站，它订阅了系统中所有的事件，并且知道每一个事件接受者。

事件的传递机制简单描述如下：

当Event Dispatcher接收到一个被触发的事件后，他会检查事件订阅列表，逐一将事件分发到每个接收者，根据事件接收者所处的位置不同，这时会有如下几种不同的情况：

1. 假如事件接受者就在容器内部，Event Dispatcher会直接将事件发送到该接收者。
2. 假如事件接收者是在客户端（Smart Client）并且接口是Remoting，Event Dispatcher会调用Remoting的远程接口将事件发送到客户端。
3. 假如事件接收者是在客户端（Smart Client）并且接口是Web Service，Event Dispatcher会将事件发送给一个叫Event Holder的对象，这个对象负责接收所有发送给客户端的事件，并且保存下来。在客户端框架会有一个叫Event Detector的对象定时通过Web Service进行轮询来检查EventHolder中的事件。假如有事件是被发送到该客户端的，就会接受该事件数据并转发给客户端的事件接收方法。
4. 如果事件接收者是Web页面，在Agile Framework中也有一个功能类似Event Detector的Ajax对象也会对Event Holder进行轮询。因此在Agile Framework中业务组件所定义的事件也能被Web页面对象接收到。

以上就是Agile Framework事件分发机制的基本原理。Agile Framework是一个开源的基于.Net 2.0技术的中间件平台，目前正在开发中，更多信息请访问敏捷实验室。

因为，为了能保持最大程度的保持组件之间解耦状态，Agile Framework提供了组件之间的事件自动连接机制（Castle也提供了一个EventWiringFacility，提供了同样的功能，但是有一个比较严重的Bug：假如在系统中存在相互之间都有发布和订阅关系的组件就会造成死循环）。

在Agile Framework中使用自动事件连接非常简单，只需要对发布的事件打上EventPublisher特性，然后在订阅方法上打上EventSubscriber标记，框架就会自动的把具有相同eventkey的事件连接起来：

这样，当Publisher触发了EventPublished之后，Substriber就会接受到这个事件。

关于Agile Framework更多信息请访问：敏捷实验室

.Net开发一直缺少一个强大的先进的开发框架。微软在.Net方面的宣传和文档总是让人感觉在不断的纠缠一些技术细节，一直没有像J2EE那样从整体为采用.Net技术开发中小型企业应用软件的开发人员指出一个清晰的开发框架。Petshop和Duwamish这样的范例太小了，并且很落后于当前的开发水平，无法体现一些类似IoC容器，AOP，OR Mapping等流行的开发理念。而类似MBF这样的由微软官方推荐的企业架构又太过于庞大，并且特定于一些类似Biztalk，Sharepoint这样的商业产品，给一些中小型企业软件软件商带来很大的压力。

这些做法其实是基于利益最大化而考虑的，微软做为一家非常优秀的商业公司，这么做本身也无可厚非。但是如果抛开一些商业上的因素，熟悉.Net技术的人一定会知道.Net其实是一个技术非常先进的优秀开发平台，并且绝对有能力可以实现一个类似J2EE这样的开发架构。许多开源界的软件开发人员也知道这一点，并且世界上也有许多优秀的程序员已经做出了卓越的贡献，创造了有名的Castle、Spring.Net、Aspect#、NHibernate等。这些项目已经为构建一个“类J2EE”的的.Net开发架构做好了充分和必要的条件。

而Agile Framework则是Agilelabs Team为了这个目标尽自己的努力的成果。

Agile Framework框架是一个为了帮助快速搭建企业级应用程序的基础性平台。它采用了.Net 2.0技术，充分利用了面向对象、Web Service、多层结构、分布式部署、IoC容器、智能客户端、ORM、动态插件、工作流等先进技术，并完美的体现了SOA的设计理念。达到降低耦合、提高重用，增加系统的灵活性和可扩展性，提高开发效率和质量，节约开发成本的效果。

Agile Framework不会像微软的官方解决方案一样，只考虑使用自家的技术，也不会像某些开源社区项目一样，非开源免费产品不用，追求所谓的“零成本”，“开放”、“跨平台”。Agile Framework会尽量站在用户的角度替用户考虑问题，博采众长，综合利用各种最合适的，最优秀的技术或产品，在合理的成本条件下为用户提供一套性价比最好、最实用的软件系统。

Agile Framework框架是根据最新的Smart Client、MonoRails WebFramework、Castle IoC容器、WWF工作流引擎、XML数据库、DB4O面向对象数据库、数据挖掘、Reporting Service等技术构建的一个插件式SOA开发框架，随着时间推移，它将不断增加入更新的设计概念和功能。

应用功能特点

• Availability（可用性）：为了保证采用Agile Framework开发的应用系统具有高可用性，Agile Framework 利用了SQL Server 2005的数据库镜像功能，允许事务日志以连续的方式从源服务器传递到单台目标服务器上。当主系统出现故障时，应用程序可以立即重新连接到辅助服务器上的数据库。辅助实例几秒钟内即可检测到主服务器发生了故障，并能立即接受数据库连接。同时还采用了离线数据处理技术，使应用程序在网络设备或服务器发生故障，甚至在大停电的情况下，都能在一定程度上保证系统的继续运行。
• Scalability（可伸缩性）：Agile Framework采用的是多层分布式架构，在负载量小的时候整个系统可以完全部署到一台服务器上以降低成本，同时系统也可以非常方便的采用纵切（按照系统的功能模块来划分）、横切（按照系统的逻辑层次来划分）或者两者结合的方式将每个子模块分别部署到多台服务器上群集处理。因此当服务的负载增长时，系统能简单的通过增加服务器数量来满足需求，且不降低或得到更好服务质量。
• Performance（性能）：在表现层，Agile Framework采用了智能客户端的离线数据处理，与服务器端的交互是异步的，即使是在系统业务量非常繁重的情况下，工作站也能以极高的速度进行操作，给用户带来良好的使用体验。在中间层，Agile Framework采用了强大的动态代理缓存技术，能对调用的服务方法自动拦截，并根据不同的缓存策略进行数据缓存处理，极大的提高了服务响应速度。在数据层，Agile Framework采用了三层数据库技术，将系统数据按照活动数据、联机事务数据和联机分析数据分类，并根据这些数据的特点有针对性的采用了面向对象嵌入式数据库、XML数据库和关系型数据仓库分别保存和处理，极大提高了数据处理速度。

开发功能特点

• Transparency（透明性）：Agile Framework提供的大量的优秀特性，比如离线处理、客户端自动升级、内存数据库、缓存处理、远程调用、事务处理、日志记录等等都被内建到框架之中，对开发人员透明化，开发人员可以完全不用自己来编写代码处理这些问题。Agile Framework已经都为您提供，并且一切都是在内部进行的，程序员只需要配置一些参数选项，所开发的应用程序就能自动获得这些先进的特性。
• Extendable（可扩展性）：不需要做任何编程修改，原始的Agile Framework本身就已经是一个可以运行起来的软件系统，只是还不包含任何的业务逻辑，没有实用价值。所有的业务逻辑和用户界面都是通过一种动态的插件机制将各种特定的业务组件和界面组件“插入”到框架之中，构建起一套具有实用价值的系统软件。这种“插件式”软件设计结构非常容易被扩展，并且灵活性相当高。开发人员只需要开发和管理一些特定的业务逻辑模块，并可以根据实际情况选择插入和替换某些业务或界面插件就能达到添加和修改系统功能的目的，不需要重新编译系统。
• Loose coupling（松耦合）：Agile Framework的设计从业务组件、界面组件到子系统都完全贯通了松耦合的概念。具体体现在：每个组件都不直接依赖于其它组件，它们之间通过接口来互相通讯。每个子系统也都不直接依赖于其它的子系统，它们之间通过工作流引擎来互相通讯。这样做的好处是，无论小到一个组件，还是大到一个系统，都是可“插拔”的，当您需要添加或替换一个功能组件甚至是一个系统的时候，会非常方便，甚至都不需要中断系统的正常运行。

另：以上的介绍用语有些广告宣传的语气，如果不太习惯还请谅解：）

Agile Framework目前正在开发和完善中，等到成熟后一定会发布并且公开源代码，如果兴趣请保持关注博客园和我们的网站，我会及时的公布一些进展消息。有好的建议或者批评都请不吝赐教，希望加入我们一起开发也非常的欢迎。

关于Agile Framework和敏捷实验室的链接：

• 敏捷实验室
• Agile Framework的开发指南Wiki（In progress）
• Agile Framework整体架构图
• 关于Agile Framework架构设计方面的随笔

class BaseClass{
   public abstract void Do();
}
class Class1 : BaseClass{
  public override void Do(){
    
  }
}
class Class2 : BaseClass{
   public override void Do(){
      .
   }
}

再做一个工厂类根据不同的条件生成不同的对象：

class Factory{
  public static BaseClass Create(){
 //get conditons
 if(conditon == 1){
        return new Class1();
     }
     else if(condition == 2){
        return new Class2();
     }
}

用的时候可以这样：

class Client{
   public void Process(){
      BaseClass bc = Factory.Create();
      bc.Do();
   }
}

但是有人在看了这段代码之后，说里面有if...else...，而面向对象的编程中可以利用设计模式来替换掉if...else...的代码，而代码中出现if...else...则意味着Bad Smell。可我不明白如何来替换这段代码，用抽象工厂吗？具体的工厂类是可以直接生成产品了，但是对条件的判断代码又转移到到底采用哪个具体工厂上去。
有人有好办法吗？

 

--------------------------
盛大招聘.Net开发工程师
经典好书：.NET框架程序设计（修订版）
新闻：苏宁首战告捷 销售同比增六成
导航：博客园首页  知识库  新闻  招聘  社区  小组  博问  网摘  找找看]]>

1IWindsorContainer container = new WindsorContainer( new XmlInterpreter("../BasicUsage.xml") );
2
3container.AddComponent( "newsletter", 
4    typeof(INewsletterService), typeof(SimpleNewsletterService) );
5container.AddComponent( "smtpemailsender", 
6    typeof(IEmailSender), typeof(SmtpEmailSender) );
7container.AddComponent( "templateengine", 
8    typeof(ITemplateEngine), typeof(NVelocityTemplateEngine) );
9

首先，ComponentModelBuilder给组件生成了一个ComponentModel，这个Model实际上是用大量的反射来捕获这个组件的各种详细的元信息，就好象先给你来一次X光扫描，这个组件是什么东西清清楚楚。
建立模型的具体过程如下：

其实具体过程就是调用contributor来进行具体的信息收集，每个Contributor负责收集不同的信息，在DefaultMicroKernel中一共注册了以下7个Contributor来收集信息：

他们各有各的功能，你可以可以自己写Contributor来收集你想要收集的信息。
接下来就是发出ComponentCreated的事件，这个事件是一个容器的扩展点，可以被注册的Facility接收到。
再接下来，就是调用HandlerFactory来创建一个IHandler，IHandler的主要功能就是创建组件的激活器（Activator），每个组件都对应一个Activator，Activator根据Lifestyle管理器来创建不同生命类型的组件实例，比如Singleton，PreThread，Transient等等。
然后在EnsureDependenciesCanBeSatisfied()这个方法中检查组件的依赖是否都得到了满足，这里就是自动连接的原理，假如没有满足，Castle就循环检查以前注册的每个组件是否满足该组件的要求，或者该组件是否满足以前注册的组件的要求，假如满足就添加到组件的依赖列表中。
最后，注册IHandler，激发Registed事件（另一个扩展点），完成整个组件的注册过程。