【问题标题】：Building a large modular solution with shared components使用共享组件构建大型模块化解决方案
【发布时间】：2014-02-28 22:00:51
【问题描述】：

背景

我正在创建一个在运行时加载程序集以执行工作的工具。它会收到一条消息，说明要处理的工作类型和其他数据，然后它会找到并加载必要的程序集。这些任务程序集中的每一个都引用一个共享程序集，并且其中许多共享一个或两个其他组件。

目前，我将每个任务都包含在自己的解决方案中。最终将有大约 50 个任务，因此在这样的巨大解决方案中开发会有点笨拙。但是，为了防止任务过时，我想创建一个大型解决方案，让我们检查对共享组件的更改是否会/不会破坏任务。

当前设置

如果我对 TaskBaseClasses 项目中的类进行更改，则必须对照包含对该更改的类的引用的其他项目检查该更改。有两个任务，这没什么大不了的。当我们有 40 或 50 个任务时，打开每个任务并进行更改将是一件非常痛苦的事情。

在部署中，应用程序的设置如下：应用程序目录

以上说明了另一个问题。当我单独构建任务时，所有共享引用都是重复的。现在这不是问题，但是当我有 50 个 TaskBaseClasses.dll 副本时

所以我真的更希望（除了我较小的个人任务装配解决方案之外）有一个大型解决方案，它允许我检查所有任务在共享装配方面的一致性，并以这样的方式构建所有内容：通过在单独的地方托管共享程序集，尽可能减少二进制重复，项目可以通过相对路径引用它们。

这可行吗？我想保留开发解决方案并创建或多或少的部署解决方案。当我开始更改部署解决方案的引用时，这不会抛弃开发解决方案中的引用吗？

我们正在使用 TFS 2012（即将升级到 2013）自动构建，我最喜欢的是每晚构建大型解决方案以供测试。

我怎样才能把蛋糕也吃掉？

【问题讨论】：

【解决方案1】：

对我来说听起来不错。对更本地化的任务集使用较小的解决方案 - 可能每个解决方案只需一个任务 - 并根据需要使用大型解决方案。

另一种方法是不使用二进制引用进行任务之间的通信。考虑一种更具弹性的变化耦合，例如使用 JSON 的 HTTP 服务。以这种方式保持向后兼容性要容易得多。

当您需要共享代码时，请使用程序集引用。当您需要共享行为时，请考虑使用 HTTP 服务。

【讨论】：

感谢您的建议。我将不得不对此进行调查。实施起来有多简单？我们预计有 50 个任务，每个任务可能至少有两个自己的共享组件添加到组合中。最后，很可能会有近 150 多个程序集。
在我们的例子中，最常见的共享程序集是 ProcessTaskCommon 程序集，它具有基类和用于所有任务的公共入口点的接口。大多数其他共享程序集是数据层规范，可能被 2 个或更多任务用于将数据输入和输出数据库。现在我们将这些任务托管在一个自托管 WCF 服务的多个实例中，该服务会根据需要加载它们，但到目前为止，我们已经做到了这一点。
我只是认为，虽然 HTTP 服务需要更多的初始工作，但从长远来看它是有回报的。您可以彼此独立地扩展任务，在不同的服务器上设置它们，在云中运行它们等等。使用紧密的二元耦合，几乎不可能获得这些好处。这一切都取决于你看到你的架构在未来的发展方向。 :)

【解决方案2】：

手工制作的解决方案可能是维护的噩梦。我建议为您的项目制定严格的命名和结构约定，以便您可以轻松编写收集器和部署脚本。

【讨论】：