本文共 5557 字，大约阅读时间需要 18 分钟。
Duwamish是Microsoft提供一个企业级的分布式系统架构，如果开发企业级的分布式系统，可以模仿这种架构，如果是开发一些简单的系统，则完全可以简化。
以前也学习过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 解决方案文件中的 BusinessRules 项目实现的，它包含各种业务规则和逻辑的实现。业务规则完成如客户帐户和书籍订单的验证这样的任务。
数据访问层 － 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开发分布式系统用来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。
References:
1, 卢彦, Duwamish深入剖析-结构篇,
2, MSDN, Duwamish
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。
References:
1, 卢彦, Duwamish深入剖析-结构篇,
2, MSDN, Duwamish
下面是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。
References:
1, 卢彦, Duwamish深入剖析-结构篇,
2, MSDN, Duwamish
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。
References:
1, 卢彦, Duwamish深入剖析-结构篇,
2, MSDN, Duwamish