DuwamishMicrosoft提供一个企业级的分布式系统架构,如果开发企业级的分布式系统,可以模仿这种架构,如果是开发一些简单的系统,则完全可以简化。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

以前也学习过Duwamish范例,只是发现不同时间,不同经历,有不同的体会。正如卢彦所说的一样:通过研究Duwamish示例,高手能够领悟到.Net应用架构的设计思想,低手能够学习到.Net的编程技巧,实在是老少皆宜。

 

因此,这里再次学习并体验一次Duwamish范例。

 

1,Duwamish 7.0 结构分为四个逻辑层(FROM MSDN):

Web Presentation

Web 层为客户端提供对应用程序的访问。这一层是作为 Duwamish.sln 解决方案文件中的 Web 项目实现的。Web 层由 ASP.NET Web 窗体和代码隐藏文件组成。Web 窗体只是用 HTML 提供用户操作,而代码隐藏文件实现各种控件的事件处理。

业务外观层 Business Facade

业务外观层为 Web 层提供处理帐户、类别浏览和购书的界面。这一层是作为 Duwamish.sln 解决方案文件中的 BusinessFacade 项目实现的。业务外观层用作隔离层,它将用户界面与各种业务功能的实现隔离开来。除了低级系统和支持功能之外,对数据库服务器的所有调用都是通过此程序集进行的。

业务规则层 Business Rules

业务规则层是作为 Duwamish.sln 解决方案文件中的 Busine***ules 项目实现的,它包含各种业务规则和逻辑的实现。业务规则完成如客户帐户和书籍订单的验证这样的任务。

数据访问层 Data Access

数据访问层为业务规则层提供数据服务。这一层是作为 Duwamish.sln 解决方案文件中的 DataAccess 项目实现的。

 

除了上述四个逻辑层外,Duwamish 7.0 还包含封装在 Duwamish.sln 解决方案文件中的 Common 项目内的共享函数。“通用”(Common) 层包含用于在各层间传递信息的数据集。Common 项目还包含 Duwamish.sln 解决方案文件中的 SystemFramework 项目内的应用程序配置和跟踪类。

 

2,各个逻辑层之间的关系图(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开发分布式系统用来tiertier之间交互数据的一种方法。Common项目也被其他的项目引用,SystemFramework项目除外。

 

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

 

3,Summary

 

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

 

如果是开发本地的系统,就不要模仿Duwamish架构(看看上面获取CategoryDescription调用过程就知道了,太费劲。),如Business FacadeBusiness RulesClasses应采用fine-grained interface设计,层与层之间的交互参数也不必全部采用DataSet,适当的时候采用setter/getter就可以了,这样不仅可以提高开发效率,而且有助于提高performance, maintainability and reusability