在 Visual Studio 中将应用程序拆分为多个解决方案之前，我应该考虑哪些因素？答案

【问题标题】：Which considerations should I make before splitting an application into several solutions in Visual Studio?在 Visual Studio 中将应用程序拆分为多个解决方案之前，我应该考虑哪些因素？
【发布时间】：2012-11-12 01:15:07
【问题描述】：

过去，我的项目变得越来越难以管理，尤其是当我必须在几年后重新访问以重做或对某个部分进行重大更新而不必重做所有内容时。这一次，我专注于让“可插拔”应用程序设计变得简单和可行，让我可以在不触及所有内容的情况下重新访问和重做一个部分。

我在想这个结构：

所以我想要的是能够在有界上下文 2 上工作，并在未来几个月/几年内使用许多新功能对其进行扩展，同时保持有界上下文 1 不变。我还将处理 UI，尤其是有关限界上下文 2 的部分。我还想让用户能够在其他设备上使用限界上下文 2。

最好甚至更新有界上下文 2 的 UI 中使用的 Web 技术，因为这是我们的主要关注领域并且使用最多，因此将其放入自己的 Web 和 UI 项目中甚至可能是明智的。有一个“登陆”网站，提供管理用户和让用户登录等常用功能。

现在我正在考虑将所有这些分离到 Visual Studio 中的单独解决方案中以简化管理。但我可以为每个解决方案创建一个文件夹并将所有内容放在那里。

我的问题是推荐的方法是什么，在分成不同的解决方案之前我应该考虑什么？

是否有任何管理此问题的最佳实践？任何人都知道什么有效，什么无效？

顺便说一句：由于这是由有界上下文划分的，因此系统的各个部分之间需要进行通信，尽管没有直接依赖关系（即上下文 1 管理和维护用于注册员工的业务逻辑，这在上下文 2 中再次需要）。

更新我意识到需要更多信息。

有比这两个更多的有界上下文。它们都不像一个部门，即员工管理是当他们需要组织/存档与管理他人相关的信息并获得重要事件提醒时的上下文管理器。采购是员工在为一个部门购买商品并进行库存时所处的环境，可能有 20-40 个组织部门使用它。我正在考虑“报告”是否是一个单独的有界上下文（尽管没有非常有趣的逻辑和行为）。这些往往从提供基本功能的小规模开始，然后随着更多功能的添加和人们“发现”新的需求而增长。它们是单独更新的，我希望它们中的一些能够及时成长为更大的系统，即使它们开始解决相当基本的需求。

【问题讨论】：

有点相关，但如果您还没有，您应该查看Prism 和/或Managed Extensibility Framework 以获得用于编写具有高度解耦的应用程序/库的良好.NET 框架。它们相似，但并不严格用于相同的目的。
如果不了解您的问题领域，将很难回答。在我的脑海中，我想说每个有界上下文代表您组织中的不同部门，例如会计。对于整个解决方案来说，注册过程似乎太小了；它看起来更像是一个项目。
@RobertHarvey 感谢您的意见。对此，我已经更新了帖子，提供了更多信息。
@PatrickQuirk 谢谢。我听说过 Prism，但没有真正研究过。不过，我希望我能够在不引入另一个框架的情况下解决这个问题。
根据您的编辑，我仍然认为粒度太小，无法证明单独的项目是合理的。 EmployeeManagement 是一个项目，而不是一个解决方案。

标签： c# visual-studio design-patterns architecture domain-driven-design

【解决方案1】：

因此，您有一堆代码，并且希望在不加载与其他部分相关的项目的情况下处理代码的某些部分。那么是的，您可以将每个部分作为单独的视觉工作室解决方案。

关键是VS解决方案只是一个[.sln]文件，描述了该解决方案对哪些项目进行分组。不要仅为此目的制作项目的单独副本。您必须只维护所有项目一次（每个项目一份），然后创建单独的解决方案并包含您认为与此解决方案相关的项目（代码的这一部分）。

例如您可能会认为“员工管理”是一个仅包含 3 个（总共 40 个）项目的解决方案。然后您继续创建一个包含这三个项目的解决方案。可能您最终会拥有单独的较小解决方案，以便与其他解决方案分开工作。

您不妨考虑拥有一个包含所有项目的大型解决方案（同样，每个项目只有一个实例，但可以是多个解决方案的一部分）。这种大型解决方案可能对构建/发布准备等主要操作很有用。

我怀疑您试图夸大解决方案的重要性。实际上，您拥有的所有代码都是一个巨大的统一体，因为它们相互引用并且如果不[重新]编译其他代码就无法构建。即使您可能会尝试提出以某种方式与您的业务需求相对应的解决方案结构，但它似乎仍然是与解决方案无关的问题的另一个方向。这可能类似于解决划分为程序集、动态加载和可扩展性等问题。

结论：将代码拆分为解决方案取决于您在使用源代码时想要实现的便利性，因为这只是将源代码分成子部分，仅此而已。

编辑/添加：

您也可以决定将解决方案拆分为独立的解决方案，但这是不同的。这意味着解决方案项目只能引用其他解决方案中其他项目的输出（dll、exe）文件。当每个解决方案都将另一个解决方案视为 3-rd 方代码（没有直接的项目引用，但只有输出引用）时，可以做到这一点。

【讨论】：

唯一正确答案；我怀疑微软的意图是不将项目的构建与解决方案混为一谈，但不幸的是，使用没有自己的项目文件的“网站”项目类型打破了该规则，并且它需要的所有 msbuild 信息都在 sln 文件中。无论如何，不鼓励创建“网站”项目以支持“Web 应用程序”项目。所以 Tengiz 解释的想法是完全正确和可行的
感谢您的洞察力。你说得对，我似乎夸大了解决方案的重要性，这可能是因为我的第一个 VS 项目中的大部分网站都可以追溯到过去。

【解决方案2】：

我认为，在决定是否应该有多个解决方案时，答案是您是否真的设想在其他不同应用程序中使用构成有界上下文的一个（或多个）程序集，这将暴露所有您的有界上下文管理的用例完全相同。如果是这种情况，那么单独的解决方案是有意义的。但是，如果您的所有 UI 层在概念上都是同时发布的同一个应用程序，那么我会将其保留在一个解决方案中，除非您的项目太多以至于 Visual Studio 变得无法使用。

如果您真的要让另一个应用程序使用相同的有界上下文，我会感到惊讶。如果您考虑一下，您是否希望仅将更新版本的逻辑部署到您的 Web 服务，而不是您的 Windows 窗体应用程序？可能不会，因为逻辑更改可能会引入奇怪的问题，其中数据不是应用程序所期望的。

您所拥有的听起来像是一个平台，并且该平台的所有部分（UI 层）都应该运行完全相同的逻辑。

【讨论】：

你是对的。不会有相同有界上下文的多个版本，但 BC 将单独开发，有自己的测试项目，自己的数据库（至少看起来像）。请问您为什么要尽量避免将它们保留在不同的解决方案中？
@cfs 您可以将测试项目保留在同一个解决方案中就好了。我更愿意将它们放在一起的原因是为了简化事情。如果基础库位于单独的解决方案中，并且我需要更改 bc 和 ui 中的某些内容，我需要在单独的解决方案中执行此操作，并以某种方式将库放到 uis 可以访问它们的地方。在一个解决方案中，vs 可以为我处理这个问题。重构会变得更容易；想想数字重命名功能与拥有。

【解决方案3】：

解决方案的观点不是我猜的主要问题。我会选择在文件夹中组织我的项目。每个限界上下文一个，而 Web UI 在另一个限界上下文中（如果考虑的话，它可以被认为是它自己的一个限界上下文）。

您可能有一些共享内核，由您的所有 bc 共享，您也可以将其放在不同的文件夹中。

通常每个 bc 应该是独立的（共享程序集除外），并且您的 UI 应该只通过它们的接口知道 bc（例如 WCF 合同）

全局解决方案可能包含 (MyApplicationName.sln) 中的每个文件夹和项目，但您可以考虑仅在部分解决方案上工作的专用解决方案，例如仅包含 bc 文件夹、共享程序集和 UI 的 MyApplication_BCName如果它符合您的需求，并且您不想处理庞大的解决方案。

从小事做起，在真正需要时尽快做事。要特别注意交叉引用，在 vs 中设置的方式实际上并不重要。如果程序集是松散耦合的，那么您可以在以后随时按照您想要的方式重新排列它们。

我不是一流的程序员，我只是碰巧认为这样的事情对于我参与的最新项目来说似乎很不错，可能会在几个月内完全改变（几小时..?? ;) )

【讨论】：

谢谢！我也是这么想的。没有想过在自己的解决方案中打开一些项目，以便能够像在单独的解决方案中那样处理它们。将它们组织在单独的解决方案文件夹中，并且与 UI 的变体相同，可以将事物保留在同一个解决方案中，易于组织和部署，并且如果我愿意，我也可以在单独的解决方案中打开现有项目。
您应该考虑文件系统上的不同文件夹。在解决方案中，做同样的事情。文件系统中的文件夹！= 解决方案中的文件夹
考虑让您的命名空间遵循 MyApplicationName.BC1.restofthenamespace。如果由于某种原因您可能希望稍后将两个组件重新组合在一起，也非常方便。