一共四段 ：

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

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

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

专区地址是：http://www.agilelabs.cn/agileframework/

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

在上次关于AF框架的事件模型的随笔中介绍了AF的事件分发机制，这个事件分发机制比较好的解决了如果通过Web Services来让客户端得到服务器端事件的问题，让Web Service和Remoting的事件处理模型看上去完全一致，为在AF上开发事件驱动的应用程序带来极大的便捷。

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

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

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

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

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

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

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

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

在以前的随笔中，介绍了一些关于Agile Framework的功能部分的特点，不过都还是一些“点”的介绍，这次介绍一下Agile Framework的整体模块组成结构，让大家对Agile Framework有一个从点到面的了解。

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的事件自动连接功能，这次来详细介绍一下事件功能的实现原理。

在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框架开发企业应用程序会编写大量的业务组件，这些组件都是被作为插件插入到框架中，结构上是完全解耦的。虽然按照SOA的设计理念在每个子系统之间不应该存在直接通信，但是有时候也可能需要在组件之间通信，比如和基础子系统或工作流组件通信。

因为，为了能保持最大程度的保持组件之间解耦状态，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架构设计方面的随笔

对.Net 2.0特性的全部支持只差三个了，

namespace alias qualifier, external assembly alias and friend assemblies

MONO编译器对.Net 2.0的新特性已经实现的有：

范型（Generics）、匿名方法（anonymouse methods）、迭代器（iterators）、静态类（static classes）、局部类（partial classes）、内联警告（inline warning）nullable types（可空类型）、property accessor accessibility, covariance and contravariance, fixed size buffers

这里附上CSDN的头版文章Mono only is Mono,not .NET never中的一段话：
“1.1的框架还没有在Mono下面完全实现，而.NET 2.0又快要推出，如果你稍微那么了解一点点的Whidbey(Visual Studio 2005的开发代号），你知道.NET 2.0相对于1.1已经改变很多很多，那么Mono究竟有多少力量能够在时间上不被微软甩开太远。我这里没有答案，也许谁也没有。”

也许答案就在眼前。。。

这几天又吵得好热闹，以前我是比较热衷于这类活动的，但是现在已经失去了兴趣。无论.Net还是JAVA都是工具而已，只要你能做出客户想要的东西就可以了，就算.Net比JAVA更让人失望吧，如果我用烂工具做出的东西比你用好工具还强，那不是显得我比你牛X许多？不过这几天看帖子，还是有一些感想想记录一下，其中针对.Net大量对COM、API包装，以及不能跨平台的一些个人看法（纯技术上的）：

.NET是一个抽象层，这个抽象层正是类似三层结构中的中间层，他的好处是简化了直接对底层的开发（这个是微软一直所大力宣传的），但是同时所带来的一个好处是为将底层替换掉提供了一种方便，虽然微软没有大力宣传这个好处，但是从技术上这是不可避免的。
是的，正如大家广泛抨击的，.Net目前的大量实现都是封装了COM，WIN32API，Managed只是提供了一个接口而已。但是请注意，假如你能充分的理解面向对象思想，你就知道这个“接口”意味着什么，“接口”最大的好处就是提供了松散耦合结构。换句话说，你可以很轻易的替换其它的底层API而保持上层应用程序不需要任何修改，这个就是所谓“跨平台”的基本技术原理。
实际举一个例子，.Net中的WinForm的底层大量的调用了GDI和WIN32系统环境接口，那么是否WinForm就被绑死在Windows平台上了呢？不一定，MWF实现了Managed Winform，基本原理就是采用.Net自带的绘图接口来实现Winform的GUI界面，那么这样只要采用不同的底层绘图接口，那么Winform就能跨平台，正如你所看到的那样，他们已经用实际的行动证明了计划的可行性。
无论微软愿不愿意，.Net实际上已经跨平台了，但是我觉得这并没有出乎微软的意料，甚至微软也可能会乐意看到这个情况，至少我觉得.Net的跨平台特点让微软在战略上“进可攻（尽量保持.Net平台在Windows上的技术先进性，让用户优先采用Windows平台），退可守（如果万一操作系统失守，将来可以通过.Net作为侵蚀其它操作系统的B计划，至少可以不用推出JAVA版的OFFICE吧）。

Völcker Informatik AG，一家柏林的IT服务公司在MONO平台上成功的应用了一套基于.Net技术的解决方案。在柏林市的教育网络使用超过350台的SUSE LINUX服务器和40000台PC为150000学生提供了学籍管理服务。

使用MONO作为开发平台代替JAVA，Völcker打开了一个新的市场，并且减少了公司60%的测试时间，而不需要再雇佣5-10个新程序员。

By using Mono to port its software to Linux, Völcker has opened a new market to serve customers running both Windows and Linux platforms. Using Mono as its development platform, instead of Java, has reduced the company’s testing time by 60 percent and eliminated the need to hire 5-10 new programmers. Migrating to Linux is also paying off for its customers who are gaining all the benefits of an open source network, as well as an enormous reduction in server licensing costs.

这个是Novell公司的一篇带有广告性质的成功案例，但是我们从中看到了MONO正式在大型企业商业化的开发中占有了一席之地。

记得MONO刚出来的时候，有很多人对它充满了FUD。一时间，“MONO其实是水中月”、“MONO注定不能进行商业化开发”、“没有大型企业敢采用MONO”等言调到处可见，并且还长篇大论从市场经济技术等各个角度来证明论点。

当有人企图用一百万字的论文来证明世界上不存在黑天鹅的时候，MONO开发小组什么也没有说，只是放了一只黑天鹅在他面前。

主要是增加了对.Net 2.0新特性的支持，MONO C#编译器已经实现的有：

范型（Generics）、匿名方法（anonymouse methods）、迭代器（iterators）、静态类（static classes）、局部类（partial classes）、内联警告?（inline warning）

暂时还没有被实现的有：

nullable types, namespace alias qualifier, external assembly alias, property accessor accessibility, covariance and contravariance, fixed size buffers and friend assemblies

其它的无非就是修改了BUG和提高了性能，值得一提的是Asp.Net的性能比上一个版本提高了8倍，并且稳定性也大大的提高了。

在XP中，最让人困惑，也是在实际XP实践中实施得最少的就是结对编程，很多人不理解：XP其它的我都赞同，但是为什么要让两个人在同一台机器上编码？一个键盘两个人抢着打？空着别的机器干吗？

如果是跟我差不多时期读大学的朋友，一定有在宿舍中与别人酣战星际的经历，星际这个游戏不仅需要大量的微操和还要有全局战略意识，特别是在战争中期，不但要微操前线数量庞大的部队，还要注意整体的战略布局，如果跟高手之间的战争还要派运输机到敌人后方进行骚扰，这个时候自己往往已经是头昏脑涨不是忘造兵就是忘记抢矿（这个和程序员的工作真还有点像，在任务重工期紧的时候，不仅要去去计算内存地址还要注意设计模式）。
假如两个人一起玩就不一样了，你只要注意操作，同学可以帮你策划战略，到了差不多的时候还会提醒你应该去补农民或者出反隐形，哪怕是水平比你差的同学，作用也非常大，整局玩下来意识清晰头脑清醒，绝少出现忘记造什么建筑或者兵种的失误，而且菜鸟的还可以通过这种方式学习到高手的技巧，迅速提升水平。

大家一定知道我想说什么，对了，XP的结对编程的道理跟这个差不多，如果身边有一个人知道你具体在做什么，知道你脑袋里的想法，他可能会提醒被你不小心忽略了的东西，在碰到问题时能直接帮你出谋划策（不需要你花费一个小时先去让他了解问题是怎么回事），能够帮你理清思路规划代码，这是两个人分别在电脑上各干各的工作方式做不到的，也许项目组降低了一些编写效率，但是却减少了大量调试BUG的时间。

Socket类的Connected属性往往不能精确的判断出网络是否连接，下面这段代码可以解决这个问题

/// <summary>
/// 是否已经连接
/// </summary>
public virtual bool Connected
{
 get
 {
  try
  {
   //检查socket的状态是否可读
   if(m_socket.Connected && m_socket.Poll(0, SelectMode.SelectRead))
   {
    byte[] aByte = new byte[1];
    //因为TCP/IP协议无法精确的判断网络是否可用
    //试读一个字符，Peek参数指定读取的字符不会从缓冲区中移除
    //假如可读则表示连接可用
    if(m_socket.Receive(aByte, 0, 1, SocketFlags.Peek) != 0)
     return true;
    Close("Disconnected.");
    return false;
   }
  }
  catch(SocketException e)
  {
   OnException(e);
  }
  return m_socket.Connected;
 }
}

访问SharePoint站点用Office打开文档提示输入用户名和密码的问题确实很烦人，做企业开发往往是这样，有时候可能会因为一个无法解决的小问题造成用户对产品产生负面的印象而导致整个项目被否决掉，Kaneboy在一篇BLOG中谈到了这个问题的解决方法，这个解决办法是微软发布的，但是很多朋友提到不管用，我也试了一下，确实不起作用，后来经过一些探索，终于找到一个办法可以解决这个问题，就是将SPS站点添加到IE的本地Intranet或者信任站点中。

在MSN中跟Kaneboy交流了一下，他说估计是IE因为安全的理由，不把它认为不够安全的站点的凭证转递出来。

FreeDotNet有计划重新构建本网站，希望能在设计中尽量的使用到各种开源世界中的架构和工具，比如NHibernate，Log4Net，NUnit，AOP.Net, Spring.Net等等，同时综合.Net世界中的Duwamish，Petshop，DotText，Asp.net Forum，IBuySpy Portal等软件结构的设计，设计出一个门户型网站的框架。该框架将使用纯.Net语言（主要是C#）编写，能跨平台的运行在Windows，Linux，Unix之上，同时该项目本身也是开源的，便于大家的学习和交流。

想法很宏大，但是由于我本身时间和能力的关系，估计在短期内难以实现该计划，因此在此诚征.NET技术爱好者来共同努力和互相学习。

对该项目感兴趣的朋友请到FreeDotNet留言并留下联系方式。