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

我们有一项功能，可供同一服务器上的多个不同应用程序（客户端）使用。它最好被建模为一个服务，有一个后端数据库，并且在任何时候都只有一个版本的功能和数据库在使用

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

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

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

将功能发布为内部（基于REST）服务。使用防火墙的内部客户端可以访问它

在我们看来，1的优点似乎是性能和可能的安全性，而2可以被视为更容易设置

---

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

这是一个我曾多次努力解决的问题，除此之外，真的没有任何最佳答案。我个人认为，出于以下几个原因，您需要远离选项1：

通过让您的所有客户机共享一个二进制文件，现在您每次对其进行更改时都需要对所有客户机进行测试。现在我知道在您的具体情况下，您可能无论如何都必须这样做，因为我们可以假设您将修改位于组件后面的数据库

不要硬编码任何东西。您可以将配置路径存储在machine.config文件的AppSettings部分 至于选项2，一个替代方案是使用WCF（假设您的环境能够支持它）。然后，使用WCF，您可以使用二进制序列化的TCP传输（可能还有共享内存传输）。这两种方法都有助于缩小性能差距（尽管选项1的性能始终优于基于服务的方法）

通过使用选项2，您还可以减少重新测试所有客户机的需要，因为您可以开发自动测试来验证您的合同是否被破坏。这将允许您发布到单个位置，运行快速的自动化测试，并且知道您不会破坏客户端

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

选项2还允许您在将来需要更多CPU电源时扩展服务

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

---

最后一个建议是使用代理/门面模式将客户机与服务的实际位置隔离开来。这将允许您在不修改客户端代码的情况下随时间扩展。

我想说，使用选项1将更简单、更容易，特别是因为您只需花费额外的时间限制其余代码的可用性。（双关语！）

乔希指出WCF是一种选择，我肯定会这样做

---

这个问题正是SOA应该解决的

正如Josh所说，不幸的是，这类问题的答案通常是“视情况而定”

我是GAC的忠实粉丝，但你应该只把你确信它（几乎）完美运行的代码放在那里，并且不需要经常更新。只要一段代码处于“开发中”，就可以将它与使用它的每个应用程序一起发布