我们有一个功能供同一服务器上的多个不同应用程序（客户端）使用。它最好被建模为服务，有一个后端数据库，并且在任何时候都只会有一个版本的功能和数据库在使用。
到目前为止，我们采用了简单的 DLL 重用，其功能、配置文件和依赖项部署在任何使用它的地方。因为现在必须在多个地方进行任何更改，所以在创建新版本的功能或新客户想要使用它时，这种方法很痛苦。
我们想知道是否有更好的方法来做到这一点，并提出了两种可能的替代方案。
将 DLL（和依赖项）放入 GAC。那么问题是如何配置组件。由于客户端对配置不感兴趣，我们倾向于将配置文件存储在服务器上的硬编码路径中。
将功能发布为内部（基于 REST）服务。使用防火墙的内部客户端可以访问它。
正如我们所看到的，#1 的优点似乎是性能和可能的安全性，而#2 可以被视为设置更简单。
我们在这里遗漏了什么重要的东西吗？以前有没有人遇到过类似的情况并想分享一些见解？
这是我已经多次努力解决的问题，除此之外真的没有任何最佳答案。我个人的看法是，出于以下几个原因，您需要远离选项 1：
至于选项 2，一种替代方法是使用 WCF（假设您的环境可以支持它）。使用 WCF，您可以使用二进制序列化的 TCP 传输（并且可能有共享内存传输）。这两者都将有助于缩小性能差距（尽管选项 1 将始终优于基于服务的方法）。
通过使用选项 2，您还可以减少重新测试所有客户端的需要，因为您可以开发自动化测试来验证您的合同没有被破坏。这将允许您发布到一个地方，运行快速的自动化测试，并且知道您不会破坏客户端。
话虽如此，您可以使用选项 1 和一组好的单元测试来完成同样的事情，但根据我的经验，从长远来看，选项 2 会更容易。
如果您需要更多 CPU 能力，选项 2 还可以让您在未来扩展服务。
我个人认为选项 1 更容易设置，因为您不必处理配置防火墙、处理身份验证、设置服务等......它也更容易调试（分发应用程序会引入新类型的故障例如托管您的服务的站点崩溃并且您的客户端开始出现故障）。
最后一个建议是您使用代理/外观模式将您的客户与服务的实际位置隔离开来。这将让您随着时间的推移进行扩展，而无需修改客户端代码。
As Josh already said, unfortunately the answer for these kinds of questions is often "it depends".
I'm a big fan of the GAC, but you should only put code there of which you're sure it works (almost) perfectly, and doesn't need to be updated very often. As long as a piece of code is "in development", just publish it together with every application that uses it.
我会说使用选项 1 会更简单、更容易，尤其是因为您只需要花费额外的时间来限制 REST 的可用性。（双关语！）
Josh 指出 WCF 是一种选择，这肯定是我会采用的方式。
这个问题正是 SOA 应该解决的问题！