玄铁剑

作为架构师和开发人员，我们始终希望确信我们是在以正确的方法解决问题。因此，在开发人员领域，始终需要正确的指导。通常，此类指导来自开发人员社区，开发人员通过这个社区彼此分享经验，相互学习。但是，现在有许多新技术不断涌现，社区成员彼此可以交流的经验常常是微乎其微。因此，软件供应商提供有价值的指导也就显得愈加重要。毕竟，这些工具和技术是这些供应商设计和开发的，他们应该有好的建议教大家如何正确使用这些工具。

指导的形式多种多样，但大致可以分为两种类型：书面指导和代码为主的指导。书面指导是最常见的类型。它包括体系结构概述和白皮书、模式和做法的一般性指南（通常不涉及具体技术），以及以入门讲解和说明“如何”实现的形式专门针对具体技术的指导。

另一方面，代码为主的指导采用源代码的形式。它可以是示例代码，也可能是展示众多模式如何构成一个实际解决方案的完整的参考实现方法。代码为主的指导可以是可重用的库，也可以是自动化代码方案。代码方案可以使特定的开发任务自动化，通常使用设计器或向导从开发人员处收集对代码进行自定义的信息。

为帮助开发人员，Microsoft 的模式和做法 (p&p) 团队与产品组一起合作，针对各种技术编写了 Microsoft 官方指导。p&p 团队发布了上述所有形式的指导，包括被称为应用程序块的复杂的参考应用程序和代码库，例如 Enterprise Library for the Microsoft^® .NET Framework 2.0（Microsoft^® .NET Framework 2.0 企业库）。

p&p 团队最近开始发布软件工厂，它们采用更注重整体方法提供指导。这些软件工厂是指导资产工具、可重用的代码、文档、参考实施方法等类似内容的集合。它们有助于根据公认的模式和预定义的标准实现软件生成过程的自动化。

一般而言，安装软件工厂的目的是扩展您的开发环境，增加与指导有关的工具和资源。例如，软件工厂可能包括一些解决方案模板，借助它们，可以更轻松地开始一个新的应用程序。此外，软件工厂还可能提供在整个开发周期都能使用的向导和设计器。

软件工厂加强了架构师和开发人员之间的关系。架构师可以自定义各种通过某软件工厂提供的代码方案，然后，再将自定义好的软件工厂应用于开发团队。这为架构师提供了一种实用的机制来将他们自己的指导分发给开发人员。

软件工厂的一个主要方面是支持自动化工具。尽管 Visual Studio^® 已通过 Visual Studio 行业伙伴 (VSIP) 计划得到了很大的扩展，但该框架还远远谈不上易于使用。因此，p&p 团队开发了 Guidance Automation eXtensions (GAX) 和 Guidance Automation Toolkit (GAT)，以便架构师可以更轻松地将自定义指导应用于 Visual Studio 的使用过程。

GAX 是在 VSIP 基础上构建的运行库，用于通过指导包对 Visual Studio 进行扩展。而 GAT 是一个工具包，用于部署在 Visual Studio 内的 GAX 上运行的指导包。如果要使用现有的指导包，例如软件工厂中找到的指导包，则必须安装 GAX。另一方面，仅当要构建指导包时才需要 GAT。（重要事项：任何人都可以使用 GAT 创建新的指导包。您甚至可以从一个现有的软件工厂着手，将其指导包自定义，然后重新生成它们。）有关 GAT 的详细信息，请参阅“指导自动化工具包简介”。

p&p 团队最近发布了一些新的软件工厂，包括 Web 服务软件工厂（有时也称为“服务工厂”），下面我将详细介绍一下该软件工厂。该软件工厂旨在帮助开发人员构建始终遵循知名体系结构和设计模式的 Web 服务解决方案。

服务工厂有两种：一种用于 ASP.NET Web 服务 (ASMX)，另一种用于 Windows^® Communication Foundation（将随 .NET Framework 3.0 提供）。ASMX 版本目前已得到官方支持，可供用户使用。官方发布的 Windows Communication Foundation 版本将与官方发布的 Windows Communication Foundation 一致。不过，服务工厂的 Windows Communication Foundation 版本目前可在 GotDotNet 上的 Web 服务软件工厂社区工作区找到其社区版本。

两个版本都将安装文档和称为 Global Bank Reference Application 的完整参考应用程序。此外，每个版本均会安装多个提供 Visual Studio 自动化的指导包。例如，ASMX 版本会安装两个指导包，一个用于 ASMX 任务，另一个用于数据访问任务。Windows Communication Foundation 版本也会安装两个指导包，一个用于 Windows Communication Foundation 任务，另一个用于有关安全性的任务。指导包管理器（参见图 1）可从 Visual Studio 2005 中的“工具”菜单打开，用于启用或禁用可用的指导包。

为了简化这一问题的讨论，此专栏的其余部分将重点介绍如何使用 ASMX 指导包。在以后的专栏中，我将介绍 Windows Communication Foundation 指导包与众不同的方面。

图 1 指导包管理器 (单击该图像获得较小视图)

图 1 指导包管理器 (单击该图像获得较大视图)

在安装时，服务工厂会在“开始”菜单中创建 Microsoft patterns & practices（Microsoft 模式和做法）| Web Service Software Factory（Web 服务软件工厂）菜单项。此处有多个指向各种服务工厂资产的链接。打开 Visual Studio 2005 并创建新项目时，会发现一个称为 Guidance Packages（指导包）的项目类型。所安装的每个软件工厂都会在此处显示它们提供的模板。如果安装了 GAT，您将看到用于创建新指导包的名为 Guidance Package Development（指导包开发）的包。

选择 Web 服务软件工厂（Web Service Software Factory，ASMX），并从右侧以模版形式显示的方案中选择其一。此方案会根据服务工厂指定的体系结构创建初始解决方案结构。选择了模板并按“确定”后，便会调用方案。此方案首先会要求您指定一个前缀，以便它用于命名即将创建的每个项目（我已指定了 Coho.ClubServices.Membership 作为前缀）。当您按“完成”后，该方案会创建所有项目；生成的解决方案就是您的起点（参见图 2）。

图 2 生成的解决方案结构

在您使用指导包时，Visual Studio 会提供指导导航器（参见图 3）。您可以使用它来导航您所使用的每个指导包提供的各种指导资产。

图 3 指导导航器

指导包创建的初始解决方案的结构会与服务工厂定义的其中一个规定的体系结构保持一致。此体系结构的主要目标是企业级 Web 服务。但是，请记住，如果具体细节不符合您的要求，您尽可以自定义指导包并修改初始解决方案模板。

规定的体系结构分为三层：服务接口层、业务层和资源访问层。请注意，这些层映射到图 2 中显示的所生成的解决方案结构。此体系结构包含分层式应用程序模式（在模式和做法 (p&p) 网站上介绍），这极大地简化了大型系统中的依赖关系管理。

每一层都由若干个彼此密切相关的不同软件组件构成。该体系结构还定义了一些适用于所有层的问题，尤其是安全性、操作管理和通讯。整体的体系结构如图 4 所示。

图 4 高级服务工厂体系结构 (单击该图像获得较小视图)

图 4 高级服务工厂体系结构 (单击该图像获得较大视图)

服务接口层的组件包括服务约定和服务适配器。服务约定定义了服务可以执行哪些操作，但它不包括任何行为，例如操作的实际执行方式。这就需要定义接口，即按照消息交换模式定义的操作组。对于每个操作，都要定义交换中使用的消息类型，而每个消息类型都以可编写的数据类型的方式进行定义。服务适配器执行端点（通常称为服务主机）上显示的服务约定，负责调整该端点，使之与基础业务层相适应。

业务层包含以下三个组件：业务实体、业务逻辑和业务工作流。业务实体是一些为有关域的实际对象建模的类。它们不同于服务约定中使用的数据类型，因为它们包含行为，而且还可能包含状态。体系结构会封装业务实体，使它们不会暴露在服务边界之外。这可以确保每层内更加灵活，也让您有机会能够以不同的方式设置数据的格式，使它们符合具体的综合情况。不过，这也意味着，必须进行实体转换才能在层与层之间移动。

业务逻辑执行实际的业务行为。这些类对业务实体进行操作，以便执行所需的行动。某些业务实体非常简单，而有些实体则利用更复杂的逻辑。

业务工作流处理那些需要复杂的消息关联和状态管理的长期运行的流程。业务工作流通常由业务工作流管理产品（如 BizTalk^® Server 2006 或 Windows Workflow Foundation）来执行。

业务层在基础资源访问层之上进行操作，后者提供对数据访问逻辑和服务代理的访问。数据访问逻辑提供您与基础数据存储区交互时所需的一切，而服务代理则提供您与外部 Web 服务交互时所需的一切。图 5 显示了这些层和软件组件如何彼此关联的详细视图。这些组件中的每一个都与初始解决方案中的一个项目相对应。您可以看到，服务工厂的范围相当广泛。它提供的指导从使用者开始，再到所有方法，最后是后端数据源。

图 5 层组件和关系 (单击该图像获得较小视图)

图 5 层组件和关系 (单击该图像获得较大视图)

服务工厂包括数据访问指导包，后者为实现数据访问层中的常见任务的自动化提供了许多方案。通常，要启动方案，只需右键单击某个项目，然后从服务工厂上下文菜单中选择相应的方案即可。（在特定上下文中，每个启用的包都有一个对应的菜单。）您也可以从指导导航器直接调用方案。

要实现数据访问层，开发人员必须执行几个常见任务。这些任务通常比较单调，而且容易出错。您在此处首先想要使用的几个方案之一是 Add database connection（添加数据库连接）方案。您可以从 Host（主机）项目的上下文菜单中选择它，以将其启动。该方案会要求您输入连接名称，然后要求您指定数据库连接的详细信息。在按下“完成”后，该方案会在 Host（主机）项目的配置文件中添加指定的连接字符串。

接下来，（假定您的数据库模型已就绪）您可以生成一组存储过程，其中封装了针对数据库模型中的特定表的典型操作（例如，选择、插入、更新和删除）。该方案会让您选择表并为每个存储过程操作指定名称（参见图 6）。

图 6 生成存储过程 (单击该图像获得较小视图)

图 6 生成存储过程 (单击该图像获得较大视图)

借助这些简单的方案，就不必为了满足将服务与现有的数据库模型集成的需要，而编写大量代码。除了生成代码之外，它们还让您确信，实施过程是按照经实践证明的最佳做法进行的。而且，您尽可方便地添加更多方案来满足自己的特定需要。

数据访问指导包还提供了一个方案，用于生成与基础数据库模型相对应的业务实体。此方案可以从业务实体项目的上下文菜单中调出。方案会要求您选择数据库连接，然后它会列出所有可用的表和视图。接着，您可以指定要使用的表和视图。然后，您可以针对每个表和视图自定义每个业务实体类的名称以其包含的字段。

生成的业务实体类会给原有表的设计建模。生成的代码包含一个构造函数，以便使用所提供的数据填充新的实例，使用属性访问代表表中各列的基础字段。尽管使用此方法可以生成业务实体层的大部分，但您一定需要扩展或自定义所生成的代码。该方案会以分部类的形式生成这些实体，让您可以安全地扩展或重新生成它们，而不必直接修改所生成的代码。

在业务逻辑项目中，您必须为该层手动编写大部分代码 - 您的业务逻辑类应该在业务实体类上进行操作。由于任何特定的应用程序都有其特有的业务逻辑，所以在这部分中可以自动完成的任务不多。

但是，您可以生成知道如何在生成的业务实体和生成的基础存储过程之间进行集成的数据存储库类。这一操作可使用 Create data repository classes from business entities（根据业务实体创建数据存储库类）方案来完成。该方案会要求您定义特定业务实体和存储过程之间的映射，之后，您还需要为存储库类定义要为其生成的每种方法的名称和类型。完成后，即拥有了在数据和业务层之间来回移动所需的类。

ASMX 指导包提供多个可自动完成常见服务层开发任务的方案。由于规定的体系结构不允许业务实体暴露在服务边界之外，所以在服务层中的第一要务就是定义各种用于构造消息的数据类型。

Create data type（创建数据类型）方案可用于定义由适当的序列化属性注释的、与 XmlSerializer 兼容的类。您无需改动任何代码即可定义该类。该方案基于项目命名空间、年份和月份，采用试探性的方法在定义这些类型时选择 XML 命名空间。然后，它会要求您指定构成类型结构的数据成员。

如果已经有现成的 XML 架构定义，可以使用它们来以其他方案定义数据类型。您只需将 XML 架构文件添加到数据类型项目，右键单击它，然后从架构中选择 Create data type（创建数据类型）。该方案使您的开发过程支持架构优先的设计方案。

创建好所有服务层数据类型后，就可以使用 Create message type（创建消息类型）方案来定义消息类型。该方案可在服务约定项目中找到。方案会要求您命名用于请求和响应消息的类，还会要求您指定构成每个消息结构的数据类型（参见图 7）。然后，会生成更多与 XmlSerializer 兼容的类来表示这些消息。

图 7 创建消息类型 (单击该图像获得较小视图)

图 7 创建消息类型 (单击该图像获得较大视图)

创建好所有消息类型后，就可以使用 Create service contract（创建服务约定）方案来设计服务约定定义了。该方案首先要求您指定服务约定的名称和命名空间。然后，需要您列出希望该服务约定支持的操作。对于每个操作，您需要指定方法名称（操作），接着指定该操作映射到的相应的请求/响应消息。

定义了服务约定的详细信息后，即可指示该方案生成服务实现类（参见图 8）。生成的 ASMX 类将实施您先前在该方案中定义的服务约定。

图 8 生成服务实现类 (单击该图像获得较小视图)

图 8 生成服务实现类 (单击该图像获得较大视图)

每个 ASMX WebMethod 的实现都应该调用业务层中定义的业务逻辑类。不过，要这么做，WebMethods 必须首先在服务约定类型和业务逻辑中使用的业务实体类型之间进行转换。由于这是一个常见而单调的任务，所以可用一个方案来生成转换代码。此方案名为 Create service contract translator（创建服务约定转换器），默认情况下，可在服务实现项目上调出。它提供用于在两个类之间定义映射的用户界面，而且会生成帮助转换器类中的代码。接下来，您只需在调用相应的业务逻辑之前将生成的转换器类用在 WebMethod 的实现中。

服务实现后，即可对外公开了，请运行 Expose service（公开服务）方案，以生成引用 ASMX 实现类的 .asmx 端点。此时便可以对它进行测试了。

您可能已经注意到了，生成了解决方案结构的原始方案已自动生成了一个可用作服务层测试工具的客户端应用程序。要使该客户端应用于您的特定服务方案，可能需要编写一点代码。

可用于构建和测试客户端的服务工厂方案有多个。例如，服务工厂提供了 Add service reference（添加服务引用）方案、Debug client（调试客户端）方案以及 Run client（运行客户端）方案。服务主机上还有一些与测试有关的方案，例如 View in browser（在浏览器中查看）和 Debug host（调试主机）方案。

您可能会觉得服务工厂生成的解决方案对您的特定项目而言威力太大。或者觉得它不完全适合贵组织的要求或标准。要解决此问题，可以自定义解决方案：只需修改原始方案生成的内容，然后为规定的体系结构中的各层重新分配项目职责即可。

要重新分配项目职责，必须在服务工厂菜单中选择 Unlock solution（解锁解决方案）来取消对解决方案的锁定。然后，右键单击服务约定项目，并选择 Specify project responsibility（指定项目职责）。在随之出现的对话框中，可以轻松指定各种职责（参见图 9）。

图 9 指定项目职责 (单击该图像获得较小视图)

图 9 指定项目职责 (单击该图像获得较大视图)

更改完解决方案后，应将其重新锁定。您也可以导出修改后的解决方案模板，以便能够根据修改后的解决方案再生成指导包的自定义版本。

Web 服务软件工厂提供了许多有价值的指导资产，借助它们，就能在开发 Web 服务解决方案时加快速度，提高质量并保证一致性。它包括有用的书面指导，以及阐述了规定的体系结构、模式和实践做法的完整的参考应用程序。此外，服务工厂还提供了多个指导包，可自动完成许多常见的开发任务。

建议您下载 Web 服务软件工厂 (Web Service Software Factory ) 并了解其诸多功能。您还可以了解 MSDN^® 的动手实验套件（可从 GotDotNet 网站获得），进行逐步演练。