WCF是另一个最佳实践
本文关键字：最佳 另一个 WCF | 更新日期: 2023-09-27 18:26:39
好吧，我已经构建了我的WCF服务，它的功能非常好！然而，我现在开始将其实现到我们预先存在的软件中，我立刻遇到了一个问题，我是否只使用代理生成的代码，并去掉我最初使用的dll？还是我两者都保留，并使两者之间的区别非常明显？
我所说的保持区别的意思是，有一个ServerUser和一个LocalUser属性来表示同一个用户对象。但是，如果应用程序服务不可用，我的LocalUser属性将通过应用程序最初运行时使用的dll填充。
我对这种思维模式的主要原因是，如果我删除dll，我就有一个失败点。如果由于某种原因，我的ServiceHost没有启动和运行，但DB服务器已经启动和运行了，我希望我的用户仍然能够完成他们的工作。新WCF实现所使用的功能并不依赖于员工的工作。WCF服务提供了更多的便利。此外，将这种逻辑构建到服务将允许在非IIS托管环境中更容易地进行服务修改。
此外，是否有一种方法可以在服务上构建逻辑，以便当我为客户端提取代理代码时，它只知道在ServiceHost不可用的情况下手动访问DB？如果这是可能的，我想我90%的问题都会消失。
提前谢谢！
根据您的描述，保留现有DLL（即直接访问数据库）最适合您的需求。如果WCF服务失败时，您只需要使用DLL，那么它不会增加任何内容。
理想情况下，您应该完全使用WCF服务，并提供某种冗余来处理任何潜在的服务问题。此外，使用服务将意味着您不必处理任何DLL升级/部署。
但是，从你的问题来看，如果服务不可用，听起来会有一些真正的问题需要处理，所以只需使用DLL即可。
编辑：只需阅读你问题的最后一部分，我认为这是不可能的。访问服务的代理代码是在向项目添加引用时生成的。你想要的那种"动态"信息实际上需要一项服务。
编辑：作为我下面评论的后续，你可以通过创建一个DLL和类来测试这一点，让我们称之为Class1。然后使用将返回Class1的方法创建WCF服务。创建客户端应用程序并添加对服务的引用。如果你查看代理生成的代码，你应该会看到（希望……我在输入时会想到这一点：）该方法返回Class1，但当你编译时，它将无法找到Class1。这是因为Class1没有在客户端上自动生成Class1的DataContractAttribute。因此，您必须将共享DLL分发到客户端。现在，当方法返回并且WCF尝试重新创建Class1时，它将使用共享DLL中的本地版本。客户端上已经存在的其他DLL将使用相同的共享DLL。