业务分层
依据行业经验来看，分层是解决复杂问题的简单方法，通过分层，可以把一个复杂问题分解为不同层次应用的小问题，解决各层小问题的难度小于总的问题难度；分层最成功能莫过于计算机网络通信协议,ISO/OSI、TCP/IP。
在信息系统开发中，我们也对一个应用按逻辑上划分为三层：数据层、业务层、界面层，其业务逻辑如下图所示：
大家通俗的对这样的结构称之为三层结构，或者演变为N次结构（对其中的某一层进行分解），两层结构（合并界面与业务为一个层，或者合并业务层与数据访问层）或者一层结果（所有的都在UI层）。
分层的架构设计或者实践在于应用开发的需求以及开发人中技术相制约，只有选择合适的分层模型，没有最优的分层模型。
AgileEAS.NET平台的分层
AgileEAS.NET平台应用开发提供了2-3/N的分层实现支持，开发人员可以根据应用系统的规模选择不同的分层模型，下面我就从2层结构开发说起：
这种2层的结构在程序部署有两个程序集支持一个应用；一个是UI部，另一个是数据访问层部分，UI和数据访问层共同完成了业务层的功能，UI偏重于业务的输入验证，DAL层则偏重于业务的数据处理。
在AgileEAS.NET平台中，数据访问层是基于接口驱动的数据访问层，也就是说把数据访问层分解为数据访问接口层与访问实现层，如下图所示：
在上图所示的架构中，对数据访问层按照接口驱动的思想分解为数据访问层接口组件和不同的数据库访问层实现，UI只依赖于数据访问层接口，不与具体的数据库实现相关，也就是业务只依赖于声明，而不依赖于实现，这样就有一个好处，当数据访问层实现做了修改之后不会影响到界面层（UI）。
在上图结构的基础上，在UI层和DAL层加入独立的业务逻辑层就得到如下图所标的结构：
在这种结构中，系统界面层访问业务逻辑层，而业务逻辑层依赖于DAL接口层，并在运行期决定是否加载那一个DAL实现，这中结构是AgileEAS.NET平台推荐的应用分层模式，平台的数据对象生成器已经生成了基于接口驱动的数据访问层代码，在界面层开发中，AgileEAS.NET平台提供了一系统的UI与ORM对象数据绑定的实践。
AgileEAS.NET平台开发的信息系统可以运行在基于.NET WebServices、.NET Remoting技术的分布式环境中，这样我们就引伸出别一个分层结构：
这种新的分层结果增加了业务代理层和通信/传输服务(层)，最初这种结构被应用于分布式应用中，在系统界面层、业务代理层、业务逻辑层各层之间数据以ORM对象形式传递。
对于涉及到的通信/传输服务，或者说通信/传输服务层，在分布式应用中，她是一个事实存在的通道，客户端部署着界面层、业务代理层，应用程序服务器刚部署着业务逻辑层和数据访问层；但是在非分布式应用中，比如客户端联想着所有组件，那么就通信/传输服务，为了统一这种分层架构，我在AgileEAS.NET平台中，对于访问本地业务组件的这种服务搞了一个虚拟的通信/传输服务。
借助于这样和分层架构，AgileEAS.NET平台所开发的应用，可以在不修改任务程序的情况下，只修改配置文件即可实现本地程序与分布式应用程序的*切换。
关于业务逻辑层
AgileEAS.NET平台采用ORM技术来构建数据访问层代码，因为ORM已经对数据库的读取、增加、删除、和修改；从理论上来讲，数据访问层已经实现了数据的增加、删除和、修改操作，业务层只需要调用这些操作，也可以是界面层直接调用数据层的这些基础操作，这样就形成了一个弱化的业务逻辑层。
如果严格的去追究业务逻辑层可以划分独立的业务逻辑和与数据处理相关的业务层，在AgileEAS.NET平台的数据对象设计器中生成的代码是基于分部类实现的，也就是说，生成器所生成的代码中预备了一半的代码文件由程序员写与业务逻辑相关的复杂数据处理代码，而业务逻辑层接受界面层的请求调用数据访问层的数据处理方法以及完成如事务处理等。
而业务逻辑代理层组件根据业务层组件生成相应的业务代理代码，完成系统界面层请求向真实的业务逻辑层转移的功能。
UI开发
界面层开发是应用开发中非常重要的部分，软件所提供的应用都需要通过界面展示给系统最终使用人员，友好的人机交互可以让操作人心赏心悦目；而如何设计出友好、美观的人机交互界面是开发人员及美工人员功底的体现。
在AgileEAS.NET平台中，系统界面层也是应用开发中插件的一个环节，系统界面层中的某些UI需要实现AgileEAS.NET平台的插件契约，直接或间接的实现IModule接口或者使用Module属性标记模块。
AgileEAS.NET平台中提供了一系统的UI基础模板及输入验证、UI数据交互管理的辅助开发组件，以方便快速的完成UI的编码。
链接
QQ群：116773358,群一已满