WCF的PetShop讲解.docVIP

一、PetShop功能简介 PetShop前端是一个单纯的基于ASP.NET应用的Web站点，整个站点由以下三个Web页面构成： 登录页面：和一般的基于Internet的Web站点一样，采用基于用户名/密码的认证方式。在图1所示的登录页面中，实际上仅仅使用了一个Login控件。熟悉ASP.NET的读者应该很清楚，该控件和ASP.NET的成员资格（Membership）模块进行了有效的集成，通过该模块可进行用户验证。 ?图1 PetShop登录页面? 默认页面：PetShop的默认页面为一个宠物的列表，列表项包含宠物的编号、名称、类别、价格、数量和相关介绍。登录的用户可以通过点击“加入购物车”链接进行选购。默认页面的界面如图2所示。 图2 PetShop默认页面 购物车页面：在用户点击默认页面的“加入购物车”链接后，会跳转到购物车页面。如图3所示，该页面列出了当前登录用户购物车中选购的所有宠物列表。用户可以将选购的宠物从购物车中移除，也可以更新选购的数量。 图3 PetShop购物车页面 严格来说，PetShop并不是一个功能完成的在线购物的Web应用，我们甚至没有提供结帐的功能，功能的完整性并不是本案例关注的重点。接下来我们先讨论一下整个PetShop的结构。 二、 PetShop的物理结构 PetShop采用典型的基于分布式的Web应用部署，从物理结构上讲，大体上分为4个层次：客户端（浏览器）、Web服务器（IIS）、应用服务器（IIS）和数据库服务器。应用的前端展现，采用ASP.NET，整个ASP.NET Web站点部署于Web服务器的IIS中。ASP.NET Web应用本身并不承担对主要业务逻辑的实现，也不直接与数据库交互。PetShop将业务逻辑的实现定义在一个个WCF服务之中。WCF服务采用基于IIS的寄宿方式，部署于应用服务器。ASP.NET Web前端应用采用HTTP协议进行服务调用，如果两者在同一个局域网内，可以采用TCP通信协议以获得最好的性能，以及TCP协议本身提供的对可靠传输的支持。对数据库的访问发生在应用服务器与数据库服务器之间。整个物理（部署）结构如图4所示。 图4 PetShop物理（部署）结构 三、PetShop的模块划分 模块是应用最基本的组成单元，而模块化是实现高内聚、松耦合的重要途径。模块本身应该是自治的，它独立地承担着某项功能的实现。模块划分应该是基于功能的，一个模块可以看成是服务于某项功能的所有资源的集合，模块的元素可以包括可视的UI、后台代码和SQL（或者存储过程），以及存储数据等。 1、模块化设计 在进行团队开发时，模块之间的独立性确保基于各个模块的开发团队可以独立进行开发，对于大规模的应用开发，模块化是保证软件质量的重要途径。模块化对于测试也具有积极作用，因为模块化赋予了每一个模块“插件”的特质，单个模块可以以“插件”的形式动态地插入现有系统，从而保证测试的及时交付。除了开发和测试，模块化对于应用的部署及产品交付同样重要。在时间就是金钱的今天，大多软件的开发都是分阶段进行的，每一个阶段完成不同的模块，阶段性的成果需要及时向用户交付。每次交付时，整个应用应该保持稳定的状态。只有高度的模块化，才能保证动态交付的模块不会对现有的模块造成影响。 模块化以及由它带来的好处，大部分人都能够理解，但却有很少人能够正确地将其应用到实际的设计之中。很多人甚至没有意识到，一些我们习以为常的设计违背了反模块化的原则。举一个很常见的例子，菜单对于大部分应用都是必须的，我们通常的做法是将整个应用的菜单内容统一维护，将它们保存到数据库或XML中，当应用启动的时候，整个菜单被加载显示。对于应用的使用者来说，可视化的菜单结构反映应用当前能够提供的可用功能的集合，如果基于某个模块的菜单项能够显示出来，就应该保证相应模块功能的完整性。但是，由于整个菜单的维护是独立的，与模块本身无关的，所以在测试的时候就会出现这样的情形：整个菜单能够很完整地显示出来，但是随便点击某个菜单项，整个应用程序就崩溃。和开发人员联系，得到的答案是相应的模块尚未完成。这样的设计对于部署也是不可取的，因为交付一个模块，就需要对维护的菜单数据作一次修正。 如果按照模块化的原则，整个设计应该是这样：菜单的管理下放到具体的模块中，当模块加载的时候，模块自行负责加载属于自己的菜单，并添加到整个菜单树相应的位置上。对于熟悉微软软件工厂（Software Factory）的读者，应该知道微软的-客户端软件工厂，无论是Web客户端软件工厂（WCSF：Web Client Software Factory）还是智能客户端软件工厂（SCSF：Smart Client Software Factory）对于菜单，都是采用这样的设计模式。 模块的自治特性并不意味着模块