对分布式系统解决方案进行划分以便于实现
更新：2007 年 11 月
当开发小组准备好在应用程序关系图上实现支持实现的应用程序定义时，开发组长可以在 Visual Studio 中为这些定义生成项目。这些项目将和同一个解决方案中的其他项一起出现在解决方案资源管理器中。不过，也可能出现希望将解决方案划分为更小的解决方案的情况。创建仅包含应用程序的子集的更小解决方案是组织项目进行开发的一种灵活方式。在 Visual Studio 中可以将项目放入任意数量的解决方案中，因此可以创建包含这些项目的子集的解决方案。此外，将原始解决方案保留为“主”解决方案也可能很有用，这样可以在解决方案的原始范围内对更改进行协调，并在该范围内创建系统和定义部署。
.gif "说明") 说明： |
|---|
本主题中涉及的方法和指南假定使用了源代码管理。有关更多信息，请参见源代码管理下的系统定义模型 (SDM) 文档。划分解决方案时，建议您对基于文件系统的 ASP.NET 应用程序使用静态端口，默认情况下这种应用程序使用的是动态端口。对 ASP.NET 应用程序使用动态端口可能导致其任意 Web 服务使用的端口号发生更改，这会导致对应的 Web 引用中断连接。有关更多信息，请参见应用程序关系图上的 ASP.NET 应用程序概述。 |
下面各节包含有关对解决方案进行划分的更多信息：
根据主解决方案划分的解决方案
将原始解决方案保留为主解决方案
使用对划分解决方案的更改更新主解决方案
根据主解决方案划分的解决方案
在大型复杂应用程序系统的应用程序定义创建在单个解决方案中的情况下，如果将该解决方案划分为更小的解决方案，用以实现应用程序，可能会更加易于管理。每个划分后的解决方案将包含应用程序定义及其对应的项目的一个子集，包括代码文件、配置文件和 .sdm 文件。.sdm 文件中包含关联的应用程序定义的系统定义模型 (SDM) 信息。
可以采用各种策略对解决方案进行划分。例如，如果整个系统由彼此界线分明的成员系统组成，则可以选择根据解决方案中每个系统的边界创建解决方案。这样，每个解决方案中将包含由对应的系统引用的应用程序定义的项目。根据每个系统的复杂性，可以将这些划分后的解决方案进一步划分为更小的解决方案。也可以按照各个开发人员对解决方案进行划分，这样每个开发人员的解决方案中就只包括系统中自己需要负责的部分。还可以使用源代码管理对项目进行共享。不过，请注意共享项目时可能出现的一些问题。有关更多信息，请参见并发签出和更改系统定义模型 (SDM) 文档。
| 说明： |
|---|
尽管系统边界可以提供一个逻辑基础，用于将单个解决方案中的应用程序定义及其项目划分为较小的解决方案，但并非必须按这种方式划分解决方案。在各个成员系统重叠（包含相同应用程序定义的使用）的情况下，此方法就不甚实用了。 |
分割后的解决方案的内容
可以为每个划分的解决方案添加应用程序关系图，从而使应用程序定义基于该解决方案的项目中的应用程序定义 (.sdm) 文件显示在关系图上。完成划分过程后，如果适当的话，将在应用程序关系图上对所有添加到解决方案中的新项目进行反向工程。每个划分的解决方案也可能包含任何系统关系图，以便个人能够查看用到这些定义的系统。例如，可以在划分的解决方案中包含共享对某个应用程序定义的引用的系统关系图，以提供上下文。如果希望使用分布式系统设计器对部署进行评估或生成部署报告，则可以使用应用程序关系图或向划分的解决方案中添加系统关系图。如果只希望将划分的解决方案用于项目开发，则不需要在这些解决方案中出现任何分布式系统关系图。
| 说明： |
|---|
如果在应用程序关系图关闭时删除了某个 .sdm 文件，则下次在包含该项目的解决方案中打开应用程序关系图时，将重新生成 .sdm 文件。但是，此重新生成的 .sdm 文件仅包含可从另一个源重新创建的信息。在已删除的 .sdm 文件中单独存储的所有信息都会丢失。而且，对关联定义的引用可能会中断。有关更多信息，请参见应用程序关系图疑难解答。如果共享的应用程序定义并未出现在划分的解决方案中，则解决方案中包含的系统关系图上该定义的使用将显示为已中断。如果系统引用了缺失的应用程序定义，则试图对系统部署进行定义或评估是不可能的，也不会成功。有关更多信息，请参见跨系统定义模型 (SDM) 文档的同步。如果添加了任何系统关系图，解决方案中必须存在应用程序关系图。 |
将原始解决方案保留为主解决方案
将解决方案划分为更小的解决方案后，也可以将原始解决方案保留为“主”解决方案。通过采用此方法，可以时常查看和检查整个系统。此外，如果存在主解决方案并且有自己的应用程序关系图，就不需要在每个划分的解决方案中都使用应用程序关系图。
| 说明： |
|---|
并不需要保留或保持主解决方案。例如，如果可以根据 Web 服务之间的连接清楚地划分系统边界，则独立地管理每个划分的解决方案并将它们之间的交互表示为到外部 Web 服务的连接就足够了。会自动将外部 Web 服务添加到其中的 Web 服务引用跨越了解决方案边界的每个划分的解决方案的应用程序关系图中。有关更多信息，请参见用于定义应用程序的应用程序类型和原型。但是，如果希望设计较高级别的系统，在其中引用在较低级别划分解决方案中创建的系统，则可以创建仅包含所需的较低级别系统定义的系统定义。不过，为了定义和评估这些系统的部署，请确保解决方案中包含了所有引用的应用程序。 |
例如，假设一个开发小组由三个开发人员组成，分别处理三个单独的解决方案，每个划分的解决方案中都包含与应用程序定义关联的项目。这三个解决方案是一个更大的划分解决方案的一部分，这个更大的划分解决方案包含单个应用程序系统的边界。而该划分解决方案又是描述其他应用程序系统的众多其他划分解决方案之一，这些应用程序系统组成了主解决方案范围内的一个总系统。
开发小组在处理划分的解决方案时，他们会将更改签入源代码管理中。然后，开发组长就可以通过签出相应的关系图和文件根据源代码管理更新主解决方案。此操作使得对代码和配置文件的更改与适当的关系图同步。有关更多信息，请参见系统定义模型 (SDM) 概述 和系统定义模型 (SDM) 文档之间的关系。
使用对划分解决方案的更改更新主解决方案
应用程序设计师、开发组长或负责系统结构的人员可以定期使用对划分解决方案的更改对主解决方案进行更新和验证。这些人员可以签出包含分散于各开发小组的那些项目的划分解决方案，而开发小组可能直接在划分解决方案或更下一级的划分解决方案中处理这些项目。
这一点非常有用，可以用于在进行了结构更改时检查整个系统，用于验证整个系统设计是否仍然得到了正确部署，以及用于在解决方案之间传播更改。如果主解决方案中仅包含一个供所有子解决方案使用的应用程序关系图，而且是对系统进行维护的唯一位置，则定期更新和检查主解决方案也十分重要。
从源代码管理刷新了主解决方案的项目后，如果在主解决方案中打开应用程序关系图，应用程序设计师或开发组长便可以检查这些项目的更改对关系图的影响。若要查看具体的更改，设计师或开发组长可以检查已签入的更改的列表或比较代码文件中的差异。设计师或开发组长然后可以使应用程序关系图与项目代码同步，或通过签出必要的项目来解决所有的同步警告，从而使有必要进行的更改在应用程序定义以及系统定义中应用程序定义的使用中传播。
如果设计师或开发组长对这些项目的更改感到满意，则可以将这些更改签入解决方案中。否则，设计师或开发组长就应与开发小组协同解决出现的所有冲突，以使代码可与关系图同步。