Duwamish深入剖析-结构篇

　　
　　Duwamish结构分析：
　　
　　Duwamish 7.0 是一个典型的N层架构，其结构分为四个逻辑层：
　　Web 层
　　Web 层为客户端提供对应用程序的访问。这一层是作为 Duwamish.sln 解决方案文件中的 Web 项目实现的。Web 层由 ASP.NET Web 窗体和代码隐藏文件组成。Web 窗体只是用 HTML 提供用户操作，而代码隐藏文件实现各种控件的事件处理。
　　业务外观层
　　业务外观层为 Web 层提供处理帐户、类别浏览和购书的界面。这一层是作为 Duwamish.sln 解决方案文件中的 BusinessFacade 项目实现的。业务外观层用作隔离层，它将用户界面与各种业务功能的实现隔离开来。除了低级系统和支持功能之外，对数据库服务器的所有调用都是通过此程序集进行的。
　　业务规则层
　　业务规则层是作为 Duwamish.sln 解决方案文件中的 BusinessRules 项目实现的，它包含各种业务规则和逻辑的实现。业务规则完成如客户帐户和书籍订单的验证这样的任务。
　　数据访问层
　　数据访问层为业务规则层提供数据服务。这一层是作为 Duwamish.sln 解决方案文件中的 DataAccess 项目实现的。
　　比较令人困惑的是其中的业务外观层和业务规则层，很多人在学习N层结构开发的时候，听得最多的是三层结构，分别为：表示层，中间层和数据层。Duwamish的WEB层和数据访问层比较好理解，也就是传统意义上的表示层和数据层，那么业务外观层和业务规则层和我们熟悉的中间层有什么联系呢？
　　
　　设计思想：
　　
　　在Web应用程序中，有部分操作只是简单的从数据库根据条件提取数据，不需要经过任何处理，而直接将数据显示到网页上，比如查询某类别的图书列表。而另外一些操作，比如计算定单中图书的总价并根据顾客的级别计算回扣等等，这部分往往有许多不同的功能的类，操作起来也比较复杂。我们可以先想象一下，如果我们采用三层结构，这些商业逻辑一般是会放在中间层，那么对内部的这些大量种类繁多，使用方法也各异的不同的类的调用任务，就完全落到了表示层。这样势必会增加表示层的代码量，将表示层的任务复杂化，和表示层只负责接受用户的输入并返回结果的任务不太相称，并增加了层与层之间的耦合程度。
　　为了解决这个问题，我们先来看看《设计模式》一文中对Facade模式的描述：
　　意图:
　　为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
　　适用性:
　　当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
　　客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
　　当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。
　　
　　结构图：
　　　
　　上文提出的这个矛盾，正好和设计模式中Facade模式中所描述的需要解决的问题非常吻合，在《设计模式》中提出的解决的办法就是引入一个Facade对象，让这个Façade来负责管理系统内部类的调用，并为表示层提供了一个单一而简单的接口。这个Façade对象，在我们的Duwamish的设计中，就是BusinessFacade（业务外观）层。
　　
　　以下是Duwamish的结构关系图：
　　
　　我们从图中可以清楚的看到，浏览器首先调用的是表示层WEB，然后WEB将请求发送给业务外观层，业务外观层对请求进行初步的处理，判断是否需要调用业务规则层，还是直接调用数据访问层获取数据。最后由数据访问层访问数据库并按照来时的步骤返回结果到浏览器（对于图中涉及到其它的结构模块以后会分别予以详细介绍）。
　　
　　代码示例：
　　
　　以下是两种不同处理路径的代码示例：
　　获取商品目录
　　表示层调用业务外观层：
　　productSystem = new ProductSystem();
　　categorySet = productSystem.GetCategories(categoryID);
　　业务外观层直接调用数据层：
　　public CategoryData GetCategories(int categoryId)
　　{
　　if ( dsCommand == null )
　　{
　　throw new System.ObjectDisposedException( GetType().FullName );
　　}
　　return FillCategoryData("GetCategories", "@CategoryId", categoryId);
　　}
　　
　　添加定单
　　表示层调用业务外观层：
　　public void AddOrder()
　　{
　　ApplicationAssert.CheckCondition(cartOrderData != null, "Order requires data",
　　ApplicationAssert.LineNumber);
　　ApplicationLog.WriteTrace("Duwamish7.Web.Cart.AddOrder:\r\nCustomerId: " +
　　cartOrderData.Tables[OrderData.CUSTOMER_TABLE].Rows[0][OrderData.PKID_FIELD].ToString());
　　cartOrderData = (new OrderSystem()).AddOrder(cartOrderData);
　　}
　　
　　业务外观层调用业务规则层：
　　public OrderData AddOrder(OrderData order)
　　{
　　ApplicationAssert.CheckCondition(order != null, "Order is required",
　　ApplicationAssert.LineNumber);
　　
　　(new BusinessRules.Order()).InsertOrder(order);
　　return order;
　　}
　　
　　业务规则层调用数据层：
　　public bool InsertOrder(OrderData order)
　　{
　　//此处省略复杂的处理逻辑
　　if ( isValid )
　　{
　　using (DataAccess.Orders ordersDataAccess = new DataAccess.Orders())
　　{
　　return (ordersDataAccess.InsertOrderDetail(order)) > 0;
　　}
　　}
　　else
　　return false;
　　}
　　
　　总结：
　　
　　通过分析Duwamish7的结构设计，我们掌握了Façade模式，并学习到了如何通过Façade模式对应用结构进行改进，同时了解了Duwamish7的基本概念和处理流程，为以后深入分析和学习Duwamish7的的其它部分打下了一个基础。

查看本文来源