在 Visual Studio 解决方案之间共享项目

这是如何“组织”我们的“人工制品”的大问题之一......这是建筑师的灵丹妙药；）有很多方法，对于每一种方法，项目的特征以及“环境”必须是评估（项目团队、需求的波动程度、组件或模块的解耦程度等）正如@jasilva 告诉你的那样，随着项目的进展，你可以“探索这些架构”，这样一开始它就不会成为障碍或者更糟糕的是，在项目的第一步使用“超大”架构会延迟一切……正如他们会告诉你的那样，你必须走路！（确实如此）但是您可以从一开始就开始进行一些“实际改进”，毕竟它就是这样。

嗯......我们都从“只为客户”的项目开始！他们正在成长为一些软件包，可以由客户甚至作为 SaaS（多租户）进行定制。在每个步骤中，您必须“重构创建和组装的内容”，以便它可以支持新的定制要求和多个客户对同一模块的请求，例如

让我们开始吧……虽然几年前唯一的分享方式是“引用”，但今天你对组件包（你使用它的那一天的 NuGet）有了实际的改进，例如使用 DI（依赖注入）你可以做没有那么多耦合也一样，这毕竟是我们想要在每个“模块”中实现的

建议

• 尽可能开始......使用“在同一解决方案中引用”的项目。（正如您所说，由于文件数量和编译过程，它可能会很慢，难以管理）
• 如果你已经像这样工作了......随着它的成长。将它们制成组件，您可以将它们解耦并作为包安装到每个“客户端定制”中。即使在这里，优点是对于每个客户端，您都有您使用的“版本”，因此您可以将版本包添加到每个客户端（单独的项目）。甚至与样式和 javascript 相关的主题（您也可以在包中对其进行版本控制）
• 显然在这里你必须有一个内部包服务器（托管你自己的 NuGet 源）
• 当模块增长时，进一步的步骤是使用更具适应性的发布、集成、安装机制（可组合），您可以查看MEF ...拥有您的核心“什么插件”的组件，您可以通过以下方式安装复制相应的程序集
• 虽然你可以用反射来做后者（它对 MEF 更友好）

然后你可以使用我上面评论的“模块”部分，关于 CORE

1. 选项 1：拥有一个核心并执行所有操作……Web、api/服务、SaaS，这会让您想到总是发送，例如，“已连接”客户端以了解模板或它启用了哪些模块。这是由“登录”客户端“定制”的单个应用程序（您将其作为服务出售或单独安装）。这个非常容易为每个人应用更改的好处）
2. 选项 2：由客户端分隔多个项目（您甚至可以在 VS 中预先组装一个模板）并插入它们（后者的坏处是对于来自 CORE 的更改，因此更难以实现它们)

嗯...建议

建议 1：使用 MEF 修改行为（插件）

如果我不得不向您推荐一些东西，那将是... MEF -Managed Extensibility Framework这个想法很简单“能够通过复制或上传程序集来注入模块/插件”（您甚至可以拥有一个模块服务器来添加到您的“核心项目”这样您可以在 MVC 中使用 MEF

建议 2：在内部 NuGet 中分离包（模块）

您可以将某些组件制作为“模块化”并将它们与您的核心完全分离。为了使它们首先可测试和可重用......为此，您可以在单独的项目中单独创建它，然后在您自己的包存储库（内部 NuGet）中的企业级共享它们。

嗯，它们是想法和建议，

可以帮助或指导您的链接

• MEF 管理的可扩展性框架
• MEF 管理的可扩展性框架
• 在 2 分钟内用 MEF 2 注入 MVC
• 使用 MEF 的 ASP.NET MVC 可扩展性
• 如何在 MVC 中使用 FEM
• 通过定义 ControllerFactory 将 MEF 与 MVC 一起使用
• ASP.NET MVC 和托管可扩展性框架 (MEF)

这似乎是一个常见的依赖问题，您想要做的是“好”，因为您想要制作具有产品所有主要逻辑的核心，看起来它将作为自己的产品出售给多个客户，但是每个人都会有独特的东西。

这会给你一个类似于这个的架构

main 中的所有常见逻辑都在 MAIN 中，并且每个客户端都有一小部分与其他所有不同的逻辑。

在项目的后期，每个客户都会问你一些只属于他的东西，你会有这样的东西

但是你必须记住，MAIN 永远不会被客户端的请求修改，当每个人都需要一些东西时，最好将它添加到 main 并发送它来调用。

与上述

所有的逻辑，包括N个解决方案的逻辑都在主解决方案中，其想法是N个解决方案引用主解决方案的DLL。这个对吗？

• 是的，这是可以接受的，但这并不容易，而且比拥有copy/paste几乎无法维护的功能的 N 解决方案要好得多

我发现的问题是，如果客户需要特定的要求，他应该怎么做？

• 将其添加到它自己的逻辑中，并带有一个条件，例如，一个新的查询以提取由 fortnights 分隔的年度销售额，其他客户都没有请求它，但可能是他们将来需要它，下一步是什么? 在 MAIN 中添加功能并仅在客户端逻辑中引用它。

• 相反，如果客户端要求更改表示它返回它的x80 请求，对于所有客户端它都是相同的并且它在 MAIN 中，但他希望它现在返回，它必须在客户端逻辑中被覆盖，而不影响 MAIN 。consultaEjemploAAB

现在，关于如何在visual studio中组织解决方案的问题，我认为它有点主观，因为应该使用每个人最喜欢的一个，例如：

您可以拥有一个超级解决方案，您的 1000 个 DLL 具有所有主要逻辑，以及每个客户端的 mvc 和 web api 项目，也许还有它们各自的 DLL

优势：

• 一切都在一个地方

缺点：

• 项目的加载速度会变慢（实习生的 1 GB RAM 的笔记本电脑不会加载解决方案 XD）
• 代码控制（比如git、tfs等）可能不是最合适的，当有人提交时，可能会引用无意义的东西，使得跟踪提交有点困难
• 所有程序员都可以访问主代码，并且可以损坏或窃取它

您可以拥有一个核心解决方案和一个包含所有 mvc 和 web api 项目的解决方案。

优势：

• 解决方案的加载优于选项 1
• 不需要修改主代码的程序员只会使用客户端解决方案，主代码不会有风险。

缺点：

• 需要为源代码控制设置两个存储库，而不仅仅是一个

您可以拥有一个核心解决方案，并拥有与客户一样多的解决方案，包括他们的 mvc 和 web api 项目，也许还有 DLL。

优势：

• 不需要看客户 A 代码的程序员，因为他只为客户 B 工作，将无法做到，因为他只需要 B 的解决方案
• 解决方案加载速度最快

缺点：

• 您需要许多存储库或子存储库，或其他一些源代码控制策略，但是此选项最难配置。

如您所见，这在很大程度上取决于您如何组织自己，取决于您想要拥有的安全方法或配置环境的难易程度，很可能我错过了其他一些优点或缺点，但我确信西班牙语的同胞操作系统，它将对我们有所帮助。

你总会找到一千种不同的方法来解决这个问题，我与你分享我个人经验的结果，一些与其他暴露的替代方案一致，而另一些则完全不同意。

在大型公司项目中，尤其是在多公司项目中，您总会发现这种情况。

通常，客户需要根据他们的需求进行定制，这就是物理、逻辑和流程架构决策至关重要的地方。

我推荐的解决方案如下所列

多租户应用程序和软件即服务的世界**

现在这里是我的笔记。

多个项目或解决方案，每个客户 1 个。

这是最糟糕的解决方案，解决方案的项目越多，加载和编译过程就越慢。这种替代方案看起来不错，但它确实会产生很多附带问题，尤其是代码冗余。随着时间的推移，这将不可避免地发生，并且没有任何方法或流程可以阻止它。

您可以尝试保留一些“不可触碰”的核心项目，并且每个客户只有几个可定制的，但是随着解决方案的增长，您将看到由于特定客户的非常具体的需求，您将如何开始拥有核心代码泄漏将它们迁移到每个客户端。

通过设计模式和依赖注入解决方案

这个近似值稍微好一点，一个好的架构和设计模式的实现可以将你的代码解耦很多，以获得一个高度可定制的解决方案，通过配置，你可以建立对象实例的分辨率，这些对象实例的逻辑由每个客户端确定...

您不需要打开多个项目，而是根据每个客户端的需要创建自定义类，然后在安装过程中为每个客户端修改应用程序的配置，以便每个客户端使用相关的对象。

这种方法的问题在于，随着时间的推移，您的应用程序往往会变得更大、更混乱。每个新客户端都可能需要对依赖注入进行无休止的配置，最终，尽管您的应用程序具有很高的技术价值，但熵和维护工作的水平将很高，尤其是最后一部分是具有高水平应用程序的典型场景技术价值，但代码非常复杂，这将使应用程序在其生命周期内难以维护。

每个客户端的版本控制

您可以为每个客户端创建一个新的应用程序分支，在这种情况下，您将拥有一个解决方案和一组项目，但每次您必须在标准之外进行更改时，您都会创建一个新的应用程序分支。

这将使您可以灵活地将更改或新功能仅应用于特定客户，而无需创建一组不同的解决方案或项目（尽管它们将是长期的）。

这样，您必须维护一个主分支或核心分支，应用程序处于其标准版本，并确保将每个更改复制到所有分支，然后根据需要在每个分支中进行自定义。

无论如何，尽管由于过度使用模式和依赖注入而摆脱了非常复杂的项目，以及通过多个项目的解决方案导致的编译器问题，但最终您将遇到一个相当复杂的问题来管理主题版本为一个分支和另一个分支之间的许多错误和“奇怪”差异开辟了道路。

尽管如此，它仍然是软件公司最广泛采用的解决方案之一。

插件/MEF

它是一个很好的替代方案，在经过广泛测试的框架中间也提供了很大的灵活性。

但是，我不建议将它用于 LOB，尽管它有效。因为考虑到可能的更改数量，应用程序的复杂性会溢出，插件的数量可能会给您带来一些性能问题。只需看看在您安装了大量插件或扩展时 Visual Studio 的行为方式。

多租户应用程序和软件即服务的世界

对于现代来说，这是我迄今为止最好的选择！如果您的应用程序是完全多客户端的，那么您应该考虑为什么必须在每个客户端上安装您的应用程序，如果您可以在云中将其作为服务提供，从而覆盖更多的客户端，并且实施和维护成本要低得多。

关键是，即使您不想/不能/不知道如何将您的应用程序作为云服务出售，这种相同的多租户架构也会在构建和维护代码库时为您带来巨大的好处。

您所要做的就是构建应用程序，实际上就像多个客户端连接到同一个实例一样。

这意味着您的应用程序必须针对每个客户端以不同的方式运行，但由于它从一开始就知道这种情况，因此这种定制是通过从代码中解释的配置参数来实现的，而不是询问为什么连接客户端，而是询问哪些配置功能可用。为这个特定的客户建立。

所以在你的代码中你会有这样的东西

//Cargar configuración del cliente, en una LOB grande
//estos suelen ser parametros en una tabla de la BD
//usualmente solo se hace el cargue cuando el usuario 
//inicia sesión
var ConfiguraciónCliente = CargarConfiguraciónCliente();

If(ConfiguraciónCliente.PagaImpuestoIVA)
{
   FacturarIVA ConfiguraciónCliente.PorcentajeIVA);
}
elseif (ConfiguraciónCliente.ObligadoaDeclararRenta)
{
  DeclararRenta():
}