散分，公司转向！离开编程行业？

chyich 2003-06-18 03:32:56

郁闷！公司转向，转为做项目，不做软件产品，解聘N名员工，以后的软件产品也外包，我们只负责做需求、进度监督、验收！唉！难道我就不能再做程序了......郁闷啊！
近段时间也在研究duwamish7,写了一点笔记，还没完全的理解，本想到时再发给大家看，现在也贴出来了。
学习Duwamish 7.0笔记
一、Duwamish 7.0的架构
Duwamish 7.0是vs.net中微软提供的一个企业级的示例，最近在学设计方面的东西，所以有时间边看边学这个示例。做了一些笔记，和大家一起讨论。
学习Duwamish 7.0，首先要看的当然是它的一个整体的结构式，在msdn自带的帮助文件中，我们看到了它的一个整体的结构，如下图所示：

Duwamish 7.0分为四层，分别为:
l Web层
相当于是用户界面层，直接与用户交互的web窗体，从源码中我们可以看到，它有以下的一些界面页：
页面名称作用
book.aspx 用以显示图书的详细信息的页面
default.aspx 默认页，显示当天的精选书
categories.aspx 用于分类显示图书的页面，它由两部分组成，上半部分显示当天推荐的该分类的图书信息，下半部分显示该分类的
errorpage.aspx 是一个静态页面，显示一成不变的错误信息
searchresults.aspx 显示搜索结果页面，用了一个datalist控件显示搜索的结果；不支持分页
shoppingcart.aspx 购物车页，用于填写购书的订单，用datagrid控件操作，支持批量修改和更新。不支持删除，设为零时能删除；不用单击update按钮就自动更新了；update按钮用于修改订购书的数量后刷新价格。
viewsource.aspx 既然是示例，当然可以看源代码了，这一页是专门用于查看源代码的

下面的页面是用于管理用户及用户订单系统，微软专门把它放在secure文件夹下：
页面名称作用
account.aspx 新客户注册页及客户修改个人信息页；
checkout.aspx 确认购买页面，填写收货人的详细地址和联系方式，填入信用卡的信息，列出购买的清单及总的费用信息。
order.aspx 显示用户的订单信息，以供用户打印该订单

在Duwamish 7.0中，大量的运用了用户控件，各个用户控件的功能不一，用户控件统一放在modules文件夹下：
用户控件名称作用
accountmodule.ascx 对应于account.aspx页面，新客户注册页及客户修改个人信息
bannermodule.ascx 每一页都包含有该用户控件，它定义的页面的头部信息，在页面中看到的头上的哪片黑色的区域就是它了，包含一个图片，三个按钮。
categoriesmodule.ascx 每一页都包含有该用户控件，它显示了书籍的分类信息。在页面的左边的”Browse Categories”文字开始到” Behind The Scenes”文字结束就是该控件的界面内容了
checkoutmodule.ascx 对应于checkout.aspx页，因为checkout.aspx页是一个按步骤操作的页(用panel控件控制)，每走一页，checkoutmodule.ascx控件中的箭头就往前走或往后退一格。在父页面中通过控制checkoutmodule.ascx控件的Stage属性来控制
dailypickmodule.ascx 用于显示推荐的图书信息，在default.aspx页和categories.aspx页中用到
searchmodule.ascx 搜索功能控件，每页的搜索功能都由这个控件实现
viewsourcemodule.ascx 查看源码功能控件，每页的查看源功能都是由这个用户控件实现

所有用户界面层就是上述的页面和用户控件，看起来其实也不多。

l 业务外观层
什么是业务外观层，这是四层结构里面新增的东西？有什么用呢？现在我也不知道，先让我们看看Duwamish 7.0中业务层中包含一些什么？打开BusinessFacade项目，这里面的东西就是Duwamish 7.0业务外观层了，看看里面有下面的这些文件组成：
文件名称类作用
CustomerSystem.cs CustomerSystem类是客户系统的业务外观层，它为客户子系统提供了一个简单的接口，该类支持远程处理的应用程序中跨应用程序域边界访问。它继承自MarshalByRefObject类。从Duwamish 7.0中提供的visio图上看，CustomerSystem类只有三个方法，分别是：GetCustomerByEmail方法（从email和密码获得客户的信息），UpdateCustomer方法（更新客户的信息，接收一个CustomerData对象），CreateCustomer方法（当然是用于创建一个新的客户了）
OrderSystem.cs OrderSystem类用于处理订单的业务外观，它只有两个方法：GetOrderSummary方法（用于统计订单），AddOrder方法（用于新增一个订单）
ProductSystem.cs ProductSystem类用于处理书的业务外观，它的方法比较多，有五个分别是：GetCategories方法（通过分类的id获得类别自身的信息）；GetCategoryItems方法（通过分类的id获得该类下的所有的书的信息）；GetDailyPickItems方法（通过分类的id获得该类下的推荐书的信息）；GetItemById方法（通过书的id获得有关书的信息）；GetSearchItems方法（根据指定的检索字段条件以及书名的关键字查询书的信息）

看了上面业务层的类以后，我们发现所有的业务层类都只有方法，没有属性，我的理解是它是所有与用户界面有关的操作的一些方法的定义。
这两天又到微软中国网站上看看，发现了卢彦写的几篇关于Duwamish 7.0的文章其中的一篇就是有关为什么要加业务外观层的，看了后，才完全理解，下面我们来看看卢彦的这篇文章的片断：
在Web应用程序中，有部分操作只是简单的从数据库根据条件提取数据，不需要经过任何处理，而直接将数据显示到网页上，比如查询某类别的图书列表。而另外一些操作，比如计算定单中图书的总价并根据顾客的级别计算回扣等等，这部分往往有许多不同的功能的类，操作起来也比较复杂。我们可以先想象一下，如果我们采用三层结构，这些商业逻辑一般是会放在中间层，那么对内部的这些大量种类繁多，使用方法也各异的，不同的类的调用任务就完全落到了表示层。这样势必会增加表示层的代码量，将表示层的任务复杂化，和表示层只负责接受用户的输入并返回结果的任务不太相称，并增加了层与层之间的耦合程度。
为了解决这个问题，我们先来看看《设计模式》一文中对Facade模式的描述：
意图:
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
适用性:
当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。
结构图：

上文提出的这个矛盾，正好和设计模式中Facade模式中所描述的需要解决的问题非常吻合，在《设计模式》中提出的解决的办法就是引入一个Facade对象，让这个Facade来负责管理系统内部类的调用，并为表示层提供了一个单一而简单的接口。这个Facade对象，在我们的Duwamish的设计中，就是BusinessFacade（业务外观）层。

l 业务规则层
业务规则层包含各种业务规则和逻辑的实现,在Duwamish 7.0中业务规则层完成如客户帐户和书籍订单的验证这样的任务。它包含了两个类：
文件名称类作用
Customer.cs 它有一个私有的常量REGEXP_ISVALIDEMAIL，用于验证客户的输入的email地址是否正确；insert方法用于验证和新建一条客户记录；update方法用于更新某个客户的信息；GetCustomerByEmail私有方法通过email验证是否已存在该客户的信息；Validate私有方法用于验证customer数据是否正确，它通过调用类内的IsValidEmail(验证email方法)和IsValidField(验证字段的内容是否超长字段规定的长度)来验证整个customer对象是否正确
Order.cs 私有的常量MINIMUM_SHIPPING_CHARGE，私有的常量STANDARD_ITEM_COUNT。CalculateTax方法用于计算税收。CalculateShipping用于计算购物的总价格。InsertOrder方法用于插入一个订单；IsValidField用于验证字段的正确性

从上面的两个类设计来看，业务逻辑层的功能是对业务对象是否符合业务逻辑的验证，无需验证的对象则无需写其业务层，从业务外观层我们看到，CustomerSystem.类对应于Customer类，它对CustomerSystem.提交的CustomeData对象进行验证。Order类则对OrderSystem类提交的OrderData对象进行验证。但是我们看到没有对ProductSystem类的验证的对象，这是因为在Duwamish 7.0中没有提供对product（在这里是指书）对象的更新或新增操作。我想，如果它提供了对书的维护功能的话，它也肯定有这个业务规则对象。
原文请看：http://www.microsoft.com/china/community/TechZone/TechArticle/TechDoc/duwamish.asp

...全文

105 138 打赏收藏转发到动态举报

写回复

用AI写文章

138 条回复

切换为时间正序

请发表友善的回复…

发表回复

overkill 2003-08-06

打赏
举报

chyich 2003-06-20

打赏
举报

可以的话我就结帖了，再次谢谢大家！我想，我以后还会继续关注技术的。可能侧重点不同而已。

wanderzhou 2003-06-20

打赏
举报

我试过了可以下载的，
声明：空间不是我提供的，是从coolmars(mars) 处得到的，下载请用下载帐号

来自 coolmars(mars) ：
提供空间
ftp://218.98.30.2

上传：
user:upload
password:upload

下载：
user:hisdn
password:hisdn

liguiman 2003-06-20