这段时间，在dotNet各大技术社区、论坛和QQ群，越来越多的人都在讨论着同一个话题，那就是CSLA.NET，可能是因为2008新书的出版，大家都想知道2008比2005到底多了哪些不一样的内容，网友之间到处打听，寻找CSLA.NET2008的英文版和中文版电子书下载地址。我向来属于那种不太喜欢在网上的发帖回帖的那种，可能是接触电脑和网络太久了吧（从286计算机问世开始至今）基本上是看着互联网长大的，所以已经没有那么热情了，但既然大家都很关注这个架构的问题，今天不妨也发表一下我个人多年架构经验的总结，我做事的风格也是编程的风格就是追求最好的程序是一种完美和艺术的体现，当然根据物理学基本定律，完美不是一种状态，而是一种趋势，虽然没有绝对的完美，但是我们要尽可能的趋近于完美！
CSLA给出了一个可以伸缩的、灵活组合并拆分的N层程序架构，N基本在5左右徘徊，并借鉴了很多J2EE的思想，给出了一个.NET程序员定制企业级软件系统开发的基本套路，当然这样的架构绝对可以说是经验的结晶了，是多少老一辈程序员多年经验总结的结果，我认为，很多企业软件是应该按照这个架构去开发的。但是我也认为，未来的企业软件必将走向智能化的道路，传统的将程序员累个半死的开发方法，虽然规避了软件开发危机，解决了如何控制需求的变化，如何进行团队合作如何测试等问题，但始终还是太慢，做出来的东西太死板，一旦需要后期改动也是很麻烦的。
所以，我提出了一种可以很好应对客户需求变化，适应各种企业环境，满足各种业务的灵活切换，能够在不同的网络环境下运行，支持运行中修改程序的组件热插拔，能够在同一系统中让程序适应不同操作用户自动调整自身以提供更匹配的人机交互体验，并达到无人介入的自动将需求转化的为最终可用程序系统的理想境界。下面是我从2001年.NET1.0Beta2刚出世就开始不断的总结完善，并经过10年客户应用，其中不少地方符合SOA和SaaS的思想（其实这些定义都是一个概念或者说指导性的思想，当时出来这样的名词我感到很有意思，心想凡是一个优秀的架构都会往这个地方想的，而我不就是早已经这样使用了吗），多年的努力达到了今天这样的架构，拿出来和大家一起分享，希望各位程序高手多提宝贵意见。
基本架构
|
内核服务（Core） |
环境入口程序（Shell） |
|
|
主服务管理器（MainService） |
WinForm组件类 WebForm组件类 CompactForm组件类 …… |
|
|
数据服务（DataService） |
||
|
网络传输服务（NetService） |
||
|
解释器服务（Interpret） |
||
|
外围独立工具集（Tools） |
||
环境入口程序（Shell）
就是在什么环境运行程序，如果是Web项目就是打开IE的首页或者是IIS的一个网站，如果WinForm（包含手机环境）就是一个EXE文件了。但是这个入口程序很小，它只需要负责启动主进程即可，剩下的事情就是启动主服务管理器就可以了。当然别小看这个小入口程序，它还可能会具有检测系统环境、版本和是否需要自动更新等运行前的准备工作。
主服务管理器（MainService）
到这里才真正打开了一个庞大的系统，主服务管理器会根据入口程序传递过来的参数进行两种选择，启动客户端服务还是服务端服务，或者也可以是分布式系统中的一个基站服务。启动Host服务可以有很多种，可以是IIS服务、EXE程序进程或者Windows服务等，不一样的环境和不同启动参数都是用同一个主服务管理器组件（例如就是一个MainService.dll文件）来进行控制和切换程序继续运行的通道。主服务管理通过自动遍历扫描启动目录下存在的所有文件，通过.NET的Reflection反射的技术自动加载的，所以到这里系统实现了一次低耦合，即不会因为系统原先的架构限制后续新增的功能。当然凭借什么反射就需要下面的内核服务了。
内核服务（Core）
主要功能为全局变量定义、操作系统控制、公共基类和接口定义等。准确说这不是一个服务了，应该说这基本上是每一个参与这个系统的所有组件程序必须引用的基本类库，因为这样，才能通过公共的变量或者接口相互通气，达到一个整体畅通无阻，就好像人的血管和经络，连接了人体的所有器官有条理的工作。所有的反射也是基于这个组件的支持。有的人可能看了后面的介绍越来越糊涂，因为不知道怎么用，其实在使用这些动态加载的服务时根本不是直接调用里面的类型，因为那没有实例让你引用更不可能让你创建一个新的实例，所以所用的调用都是调用这里面的公共基类、接口甚至是委托代理，以解决所有问题。
数据服务（DataService）
没什么好说的，大家都知道这是干什么的，当然结合这样一个开放性的平台系统，数据服务也需要非常的灵活，首先所有数据访问通过单件模式统一入口，然后层层分离，多少层我就不管了，看你的喜好，也根据不同的数据访问技术，例如用ADO.NET等，可以先做一层使用数据操作一套基类来对数据进行初步处理，然后送入下一层针对专门的数据库，是SQL还是Oracle等。我一般使用的CommandBuilder这是一个很好用的功能，它可以根据任何表自动生成添加更新和删除操作的SQL脚本，并结合DataSet将数据传来传去，你会发现用了很少的与业务无关的代码，解决了很多问题。这时有人会提到性能的问题了，我声明这套系统不考虑性能是否足够好，只追求是否用最少的代码解决最多的问题，至于性能我相信，硬件的发展速度是比软件快的。
网络传输服务（NetService）
现在.NET里最新的最完整的技术就是WCF了，所以我现在就是用WCF来做这个层的，曾经用过Socket、WebService和Remoting，但那都是过去式了，但不排除你是高手，为了追求性能自己写TCP传输类。而且一个好的网络传输层是要支持分布式的，那样这就不是一层的问题了，是可以组成蜂窝网络的，最基本的也要有客户端和服务端的功能实现，而且还要考虑和数据服务进行很好的通信，例如我现在的系统中就是通过一个变量标志是SQL直连还是WCF到服务端再连SQL，这样数据服务的前置层判断是否转给网络传输层先让其WCF到服务端，那么服务端的HOST接收到数据后，再判断是否连本网络内的SQL服务器还是继续分布式到更高级次的服务器HOST，以此类推，直到这个数据找到了其目标SERVER或者被中途的SERVER强制处理都可以轻松实现。这层中还有许多小的功能例如压缩传输、流量统计与控制、网络中断的缓存技术和断开再连接的自动数据更新技术等。这些功能目前的系统都已经一一实现。
解释器服务（Interpret）
记得在很多地方看到关于设计模式的介绍时，在解释器模式这一章里经常看到作者说这个模式很少被用到，介绍也是一带而过，其实往往越是不常用的东西，其威力越是巨大（例如核武器^_^），在我的这个架构中，解释器服务是必不可少的一个环节，其代码不多，但却起到了一个承上启下的作用，为单调的Service模式增添几分色彩。我目前用到的包括：通用组件解释器、模板解释器、工作流解释器、报表解释器还有一个数据窗体解释器。其实这里的解释器没有什么固定的，你完全可以根据你的需要自己来定制各种各样的解释器，因此什么样的解释器就不是我架构的核心部分了，我这里主要是举个实际例子。例如里面的数据窗体解释器就是我将所有窗体的参数存储在数据库中，在运行时自动将设置数据解释为实际窗体实例的，这样你在我的程序代码中看不到任何一个承载业务的窗体，但在运行后有成百上千个不同界面的窗体来实现业务需要的功能。不仅如此，这么做的另一个好处就是为程序自动根据需求文档生成界面提供的平台基础。
当然解释器不是独立工作的，大量的具体工作解释器会像分配工作的部门经理一样，全部推给各个具体的组件（就像各个岗位上的员工一样），他们才是最终的苦力。下面的层次是成套的，就是根据不同的环境来做具体实现了。到这里我们才真正的进入目标框架的开发，也就是说以上的几个服务是与环境无关的，哪怕是在手机上运行CompactFramework简版.NET环境都不怕，而平台是完整提供的，具体使用哪一套，那就是分配工作的解释器自然知道的问题了。由于本文以介绍架构为主，往后就不详细展开了，只是在WinForm里举几个例子，以供参考。
WinForm组件类：例如：菜单、工具栏、状态栏、对话框、导航面板、帮助界面、数据查询界面、商业逻辑、数据窗体系统、报表设计器和浏览器等。其实这里还可以根据CSLA中的介绍再次将每个设计分成表示层和界面层，所以说这是一个很开放的架构，它将我们传统的层次分类更加灵活的运用，以追求最完美的效果。
外围独立工具集（Tools）
外围工具集可有可无，主要为了整个系统运行提供一些方便的小工具，其意义大家都明白，就不用我废话了，就举几个例子吧，例如：更新工具、打包工具、脱离Framework工具、安装工具、备份工具、报表工具等等。
再次声明，上面所述不是我有感而发，而是我现在已经开发完的，并且正在我所有客户那天天都在跑的程序系统，虽然还有不少需要完善的地方，但整体架构就如上所述，我今天就是花点时间整理成文字而已。好了，今天就先介绍到这里，有兴趣的读者可以与我联系，我最近也在考虑将现有这个架构的程序转为开源的项目，毕竟一个庞大的完美的系统，绝对不是一个人的力量就可以完成的啊！