开始研究企业应用架构

很早就想研究下企业应用架构,一直没时间(要学的东西太多了,真的感觉时间不够.....).最近项目第一阶段的完成,有了一点恢复精神的时间,正好来研究下企业应用架构,首先一般的架构是分为三层(谁都知道,呵呵):UI层;BUSINESS层;DATAACCESS层;   这是我原先知道的,但是这是大体上的分层,如果加上,抽象层,实体层,服务,ORM,还有一些辅助层(总之就是细化了),该怎么规范化命名以及各层之间的关系就不是很清楚了,今天看了3篇文章,很有帮助,根据上面的介绍准备去把petshop,Duwamish,Fitch and Mather 下载下来研究研究.
那三篇文章分别是:
http://www.cnblogs.com/rexsp/archive/2004/09/16/43815.aspx
petshop
http://blog.csdn.net/thebesghost/archive/2006/08/02/1008782.aspx
Duwamish
http://blog.csdn.net/cngkqy/archive/2006/05/19/745229.aspx
http://blog.csdn.net/cngkqy/archive/2006/05/19/745229.aspx

下载地址:
C:\Program Files\Microsoft Visual Studio .NET 2003\Enterprise Samples\下就有Duwamish,Fitch and Mather
petshop是到google上搜索下好了

今天打开Duwamish例子一看,原来vs上有一个"企业级摸板项目",里面已经把一个项目划分7层,分别是:BusinessFacade(业务外观层);
BusinessRules(业务规则层);DataAccess(数据访问层);System(系统框架层);Web服务(服务层);Web/Windows UI(UI层);
每层都只能完成各自的任务,如果使用了不属于自己的东西,就会有警告(当然对系统运行不会有影响)
各个逻辑层之间的关系图（FROM MSDN）及其调用Sequeance图示例：

下面是Categories.aspx web页面获取Category的Description的整个调用过程。

（1）实例化ProductSystem对象

（2）调用ProductSystem的GetCategories()方法

（3）检测参数的合法性

（4）创建Categories::DataAccess对象实例

（5）返回上述对象

（6）调用Categories::DataAccess对象的GetCategories()方法

（7）创建CategoryData::Common对象实例

（8）返回上述对象

（9）返回CategoryData::Common对象实例，该实例中已经包含了需要的数据

（10）返回CategoryData::Common对象实例给web/Client端

（11）检测数据的合法性

（12）读取并显示结果：Category的Description

SystemFramework项目包含一些application需要的配置参数，ApplicationLog日志类和ApplicationAssert参数校验类。SystemFramework项目为所有其他的项目所引用。

 

Common项目包含了用于在各层间传递信息的数据集，如上述的CategoryData继承System.Data.DataSet，既不是所谓的typed DataSet，也不是一般的DataSet，不过简单实用，这是基于.Net Remoting开发分布式系统用来tier与tier之间交互数据的一种方法。Common项目也被其他的项目引用，SystemFramework项目除外。

 

BusinessFacade项目中所有的Classes继承MarshalByRefObject class，显然是让准备将BusinessFacade tier部署为Remote Objects。不过，实际上默认这里并没有将其部署为Remote Objects，Web层仍然调用本地对象（《Duwamish部署方案篇》将分析这个问题）。

3，Summary

 

在开发基于.Net Framework企业级分布式系统时，上述架构值得推荐，但也并非完美无暇，实际上存在一些值得改进的地方。显然，不可能一个范例适合所有的实际情况么，要求太苛刻了。其实，Enterprise Samples中的另外一个范例Fitch and Mather 7.0，其架构和Duwamish就有些不同了。

 

如果是开发本地的系统，就不要模仿Duwamish架构（看看上面获取Category的Description调用过程就知道了，太费劲。），如Business Facade和Business Rules中Classes应采用fine-grained interface设计，层与层之间的交互参数也不必全部采用DataSet，适当的时候采用setter/getter就可以了，这样不仅可以提高开发效率，而且有助于提高performance, maintainability and reusability。
下面是petshope的架构的一些介绍:
主题架构都是如下:

分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。


PetShop4.0的系统架构图如下所示：

在数据访问层（DAL）中，仍然采用DAL Interface抽象出数据访问逻辑，并以DAL Factory作为数据访问层对象的工厂模块。对于DAL Interface而言，分别有支持MS-SQL的SQL Server DAL和支持Oracle的Oracle DAL具体实现。而Model模块则包含了数据实体对象。其详细的模块结构图如下所示：

图六：数据访问层的模块结构图

可以看到，在数据访问层中，完全采用了“面向接口编程”思想。抽象出来的IDAL模块，脱离了与具体数据库的依赖，从而使得整个数据访问层利于数据库迁移。DALFactory模块专门管理DAL对象的创建，便于业务逻辑层访问。SQLServerDAL和OracleDAL模块均实现IDAL模块的接口，其中包含的逻辑就是对数据库的Select，Insert，Update和Delete操作。因为数据库类型的不同，对数据库的操作也有所不同，代码也会因此有所区别。

此外，抽象出来的IDAL模块，除了解除了向下的依赖之外，对于其上的业务逻辑层，同样仅存在弱依赖关系，如下图所示：

图七：业务逻辑层的模块结构图

图七中BLL是业务逻辑层的核心模块，它包含了整个系统的核心业务。在业务逻辑层中，不能直接访问数据库，而必须通过数据访问层。注意图中对数据访问业务的调用，是通过接口模块IDAL来完成的。既然与具体的数据访问逻辑无关，则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现，只要不涉及到IDAL的接口定义，那么业务逻辑层就不会受到任何影响。毕竟，具体实现的SQLServerDAL和OracalDAL根本就与业务逻辑层没有半点关系。

因为在PetShop 4.0中引入了异步处理机制。插入订单的策略可以分为同步和异步，两者的插入策略明显不同，但对于调用者而言，插入订单的接口是完全一样的，所以PetShop 4.0中设计了IBLLStrategy模块。虽然在IBLLStrategy模块中，仅仅是简单的IOrderStategy，但同时也给出了一个范例和信息，那就是在业务逻辑的处理中，如果存在业务操作的多样化，或者是今后可能的变化，均应利用抽象的原理。或者使用接口，或者使用抽象类，从而脱离对具体业务的依赖。不过在PetShop中，由于业务逻辑相对简单，这种思想体现得不够明显。也正因为此，PetShop将核心的业务逻辑都放到了一个模块BLL中，并没有将具体的实现和抽象严格的按照模块分开。所以表示层和业务逻辑层之间的调用关系，其耦合度相对较高：

图八：表示层的模块结构图

在图五中，各个层次中还引入了辅助的模块，如数据访问层的Messaging模块，是为异步插入订单的功能提供，采用了MSMQ（Microsoft Messaging Queue）技术。而表示层的CacheDependency则提供缓存功能

接下来就是Fitch and Mather的架构介绍:
Fitch and Mather 7.0 结构分为三个逻辑层：

• 用户服务层 (USL)

  用户服务层为客户端提供对应用程序的访问能力。Fitch and Mather 7.0.sln 解决方案文件中企业级模板项目 (ETP) 节点下的 Web 项目实现此层的功能。

• 业务逻辑层 (BLL)

  业务逻辑层提供用于处理帐户、买卖股票和研究公司的业务逻辑。Fitch and Mather 7.0.sln 解决方案文件中企业级模板项目 (ETP) 节点下的 BLL 项目实现此层的功能。

• 数据访问层 (DAL)

  数据访问层为 BLL 提供数据服务。Fitch and Mather 7.0.sln 解决方案文件中企业级模板项目 (ETP) 节点下的 DAL 项目实现此层的功能。

除了以上描述的三个逻辑层，Fitch and Mather 7.0 还包含 Fitch and Mather 7.0.sln 解决方案文件中企业级模板项目 (ETP) 节点下的“公共”项目中所封装的共享函数。另外，普通会计模块 (GAM) 是一个 COM+ 组件，该组件是以 Fitch and Mather 7.0.sln 解决方案文件中的单独项目的形式实现的。

结构关系图

层间交互

Fitch and Mather 7.0 结构允许使用多种不同的分布式或非分布式部署方案。因为 .NET 程序集和 USL 是可以单独部署的单元，所以各种部署方案都是可能的。尽管可将这些程序集物理部署为任意配置，但由于性能原因，在选择部署方案之前，应考虑层间交互的问题。例如，BLL 与 DAL 之间的紧密交互要求确保将这两个单元部署在一起。相比而言，BLL 与 USL 的关系不紧密，因此，可以很容易地以分布式方式部署 BLL。

数据库

所生成的 Fitch and Mather 7.0 的 DAL 要求使用 SQL Server 2000。然而，可以将 GAM COM+ 组件配置为使用 SQL Server 2000 或使用 Oracle 8.0。

注意   在 GAM 被配置为使用 Oracle 时，应用程序的其余部分必须仍使用 SQL Server 2000。

数据库	注释
SQL Server 2000	使用在 [安装 Visual Studio .NET 的驱动器号]:\Program Files\Microsoft Visual Studio .NET 2003\Enterprise Samples\FMStocks7\DataBase\SQLScripts\ directory 目录中定义的存储过程和架构。
Oracle 8.0	使用在 [安装 Visual Studio .NET 的驱动器号]:\Program Files\Microsoft Visual Studio .NET 2003\Enterprise Samples\FMStocks7\DataBase\OracleScripts\ 目录中定义的存储过程和架构。

注意   Fitch and Mather 7.0 数据库是静态的，它并不反映当前股票的价值。

顶级活动关系图

下面的高级 UML 活动关系图描述进入 Fitch and Mather 7.0 Web 站点的用户可进行的操作和选择。

注意   此关系图是一个标准的 UML 活动关系图。有关更多信息，请参见统一建模语言 (UML)。

Fitch and Mather 顶级活动关系图

看了以上这些架构的介绍,应该对我们设计出符合自己要求的架构有一定的帮助,以上只是从其他地方搜集过来的,并不是自己的东西,我会整理下思路,把自己的看法帖出来.