我们有一个功能供同一服务器上的多个不同应用程序（客户端）使用。最好将其建模为服务，具有后端数据库，并且在任何时候都只会使用一个版本的功能和数据库。
到目前为止，我们一直采用简单的 DLL 重用，将功能、配置文件和依赖项部署在使用它的任何地方。因为现在必须在多个地方进行任何更改，所以在创建新版本的功能或新客户想要使用它时，这种方法很痛苦。
我们想知道是否有更好的方法来做到这一点，并提出了两种可能的替代方案。
将 DLL（和依赖项）放入 GAC。那么问题是如何配置组件。由于客户端对配置不感兴趣，我们倾向于将配置文件存储在服务器上的硬编码路径中。
将功能发布为内部（基于 REST）服务。使用防火墙的内部客户端可以对其进行访问。
正如我们所见，#1 的优点似乎是性能和安全性，而#2 可以被视为设置更简单。
我们在这里遗漏了什么重要的东西吗？有没有人遇到过类似的情况并想分享一些见解？
【问题讨论】：
标签： .net architecture service reusability
这是一个我曾多次努力解决的问题，除此之外真的没有任何最佳答案。我个人的看法是，您需要远离选项 1，原因如下：
至于选项 2，另一种选择是使用 WCF（假设您的环境可以支持它）。使用 WCF，您可以使用二进制序列化的 TCP 传输（并且可能有共享内存传输）。这两者都将有助于缩小性能差距（尽管选项 1 将始终优于基于服务的方法）。
通过使用选项 2，您还可以减少重新测试所有客户端的需要，因为您可以开发自动化测试来验证您的合同没有被破坏。这将允许您发布到一个地方，运行快速的自动化测试，并且知道您不会破坏客户端。
话虽如此，您可以使用选项 1 和一组好的单元测试来完成同样的事情，但根据我的经验，从长远来看，选项 2 会更容易。
如果您需要更多 CPU 能力，选项 2 还可以让您在未来扩展服务。
我个人认为选项 1 更容易设置，因为您不必处理配置防火墙、处理身份验证、设置服务等......它也更容易调试（分发应用程序引入了新的故障类型，例如托管您的服务的站点崩溃并且您的客户端开始出现故障）。
最后一个建议是您使用代理/外观模式将您的客户与服务的实际位置隔离开来。这将让您随着时间的推移进行扩展，而无需修改客户端代码。
【讨论】：
正如 Josh 已经说过的，不幸的是，这类问题的答案通常是“视情况而定”。
我是 GAC 的忠实拥护者，但您应该只在其中放置您确信（几乎）完美运行且不需要经常更新的代码。只要一段代码“正在开发中”，只需将它与使用它的每个应用程序一起发布即可。
【讨论】：
我会说使用选项 1 会更简单、更容易，尤其是因为您只需要花费额外的时间来限制 REST 的可用性。 （双关语！）
【讨论】：
Josh 指出 WCF 是一种选择，我肯定会这样做。
这个问题正是 SOA 应该解决的问题！
【讨论】：