业务模块间的依赖
 
    各个业务模块之间的依赖，有时候会是难以解决的问题，尤其是一些可以重复利用的业务组件，例如权限管理，邮件发送等等。管理好这些各种不同的业务组件是我们的目标，IoC容器为我们提供了最完美的方案，通过它将不同的模块注入到系统中我们可以在不知道这个组件存在的情况下调用它。但目前只有不成熟的Spring.Net一个选择，我们只有一声叹息，因此也就不多讨论了。

    业务数据访问层 

    业务数据访问层是一个针对具体应用系统的专属层，它为业务层提供与数据源交互的最小操作方式，仅仅是业务层需要的数据访问接口，业务层完全依赖业务数据访问层所提供的服务。这些服务负责从业务层接收数据或返回业务实体，它屏蔽了实际业务数据与机器存储方式的差别。当然，数据层选用抽象的解决方案同样可以达到这个效果，但业务数据访问层最大的特点就是针对具体业务做抽象，而抽象的数据层访问方案是针对通用做抽象。往往业务中针对具体的设计生命力会变的更强，这样我们可以最大限度的保持了上层代码的复用性，当需要更换存储策略如果数据层访问差别太大，通过更换数据层无法解决问题的时候我们最多只需要更换业务数据访问层，而无需改变业务层。

    业务数据访问层由DAO（Data Access Object）层和系统服务层两部分组成。DAO层为每个业务实体提供最基本的数据访问服务，系统服务层为系统全局提供与业务关系不大的通用数据访问服务，这两层处于系统中的同一个层次位置。

    业务层与业务数据访问层关系图

    数据层

    数据层的宗旨就是为数据源提供一个可供外界访问的接口，我们应该选用一种能够提供数据源无关的抽象数据访问接口并通过在其下挂接各种不同的DataProviador来访问数据源的数据层组件，这样做便于移植到不同的数据源上。目前有以下3种数据层方案：

    1. 1. 封装ADO.Net

    这些数据访问组件都是基于ADO.Net的浅封装，它的优点在于封装层次低所以速度最快，我们可以手动组织sql语句用来适应复杂的操作以及个性的优化等。缺点是无法直接处理自定义数据实体方式的业务实体对象，需要将业务实体中的数据属性以参数形式传入传出。这样的方式虽然最为保险，但随着系统规模增大，开发效率，质量，，后期的维护，二次开发都变成尤为突出的问题，对开发人员的要求会变的越来越高。另外对于事物操作封装不是很好，无法提供声明性事物，经常会在业务层出现访问数据层的需要。这样的组件目前应用的很广泛，例如微软在EnterpriseLibrary中提供的DAAB（Data Access Application Block），还有以前的DAAB3.1。EnterpriseLibrary是个成熟的产品，包括了数据访问，异常，日志，缓存，加密，配置,安全等组件做为通用服务非常适合。

    2. 2. OR-Mapping组件

    ORM是最好的数据持久解决方案，它的优点在于能够以面向对象的方式操纵数据，因此可以直接处理自定义数据实体的业务对象，我们根本不用操心sql语句以及底层存储方式，这样极大的简化的代码提高了开发效率，对于日后维护扩展都带来极大的便利。缺点在于屏蔽了底层使得我们无法针对具体数据源做优化，而且对于复杂关联的sql操作有些力不从心，同时性能也差一些但辅助以缓存情况会好很多，而在dotNet下最大的问题就是没有一个成熟便宜的ORM产品供我们使用，全部都是beta版本和商业版本。这些版本或多或少都存在一些问题，以至于真正应用中需要经过仔细考察。例如NHibernate，Gentle.Net，XPO，Grove.Net等等非常多。

    3. 3. DataMapper（SqlMapper）

    SqlMapper为以上两种方式提供了一个折中的选择，它可以以面向对象的方式直接处理自定义数据实体的业务对象，同时可以根据与数据源与业务实体的映射关系执行手写的sql语句，这样完全使得我们可以针对具体数据源做优化，对于复杂操作同样可以胜任。目前只有iBatis.Net一个产品，它是一个java移至的开源项目，已经比较成熟，可以在无需编译的情况下随意替换DAO。

    至此，整个架构方案的讨论已经完成，我们可以看出dotNet下可供选择的解决方案是那么的有限，反看Java世界，有那么多成熟可供利用的组件框架，流口水中...不过dotNet也正在走向成熟，我们需要时间等待。这个架构设计的思路只代表了我个人的理解，而且也并不是说所有的开发都是这么一套方案，在具体环境中需要做具体的调整。希望能起到一个抛砖引玉的作用。我的邮箱是i-simon AT msn.com，由于我经验尚浅，有不正确或不足的地方欢迎指正讨论，另外本文将根据技术的最新进展持续更新。