.net - 基于服务器的重用 - DLL、GAC 或 REST？

Question

我们有一个功能被同一台服务器上的几个不同的应用程序(客户端)使用。最好将其建模为服务，具有后端数据库，并且在任何时候都只有一个版本的功能和正在使用的数据库。

到目前为止，我们已经采用了简单的 DLL 重用，功能、配置文件和依赖项部署在使用它的任何地方。因为现在必须在多个地方进行任何更改，所以在创建功能的新版本或新客户想要使用它时，这种方法很痛苦。

我们想知道是否有更好的方法来做到这一点，并提出了两种可能的替代方法。

1. 将 DLL(和依赖项)放入 GAC。接下来的问题是如何配置组件。由于客户端对配置不感兴趣，我们倾向于将配置文件存储在服务器上的硬编码路径中。

2. 将功能发布为内部(基于 REST 的)服务。对它的访问可以仅限于使用防火墙的内部客户端。

正如我们所见，#1 的优点似乎是性能和可能的安全性，而 #2 可以被视为更易于设置。

我们在这里遗漏了什么重要的东西吗？有没有人以前遇到过类似情况并想分享一些见解？

Answer 1

这是一个我已经纠结过很多次的问题，除了视情况而定，确实没有任何最佳答案。我个人认为，出于以下几个原因，您需要远离选项 1:

1. 通过让您的所有客户端共享一个二进制文件，现在您每次对其进行更改时都需要测试您的所有客户端。现在我知道在你的确切情况下你可能不得不这样做，因为我们可以假设你会修改位于组件后面的数据库。
2. 不要硬编码任何东西。您可以将配置路径存储在 machine.config 文件的 AppSettings 部分中。

至于选项 2，一种替代方法是使用 WCF(假设您的环境可以支持它)。使用 WCF，您可以使用二进制序列化来使用 TCP 传输(并且可能有共享内存传输)。这两者都有助于拉近性能差距(尽管选项 1 总是优于基于服务的方法)。

通过选择选项 2，您还可以减少重新测试所有客户端的需要，因为您可以开发自动化测试来验证您的契约(Contract)没有被破坏。这将允许您发布到一个地方，运行快速的自动化测试，并且知道您不会破坏客户端。

话虽如此，您可以使用选项 1 和一组良好的单元测试来完成同样的事情，但根据我的经验，从长远来看，选项 2 会更容易。

选项 2 还允许您在未来需要更多 CPU 处理能力时扩展服务。

我个人认为选项 1 更容易设置，因为您不必处理配置防火墙、处理身份验证、设置服务等...它也更容易调试(分发应用程序引入了新的故障类型，例如托管您的服务的站点崩溃，您的客户开始出现故障)。

最后一个建议是您使用代理/外观模式将您的客户与服务的实际位置隔离开来。这将使您可以随着时间的推移进行扩展，而无需修改客户端代码。