好的，所以我已经构建了我的WCF服务，它的功能很棒！但是，我现在开始将它实现到我们现有的软件中，我立即遇到问题，我是否只使用代理生成的代码并摆脱我最初使用的dll？或者我是否同时保留两者，并将两者区分开来非常明显？
通过保持区别，我的意思是，具有表示相同用户对象的ServerUser和LocalUser属性。但是，如果应用程序服务不可用，我的LocalUser属性将通过应用程序初始运行的dll填充。
我对这种思维模式的主要推理是，如果我删除了我的dll，我只有一点失败。如果由于某种原因我的ServiceHost没有启动并运行，但数据库服务器是，我希望我的用户仍然能够完成他们的工作。新WCF实施所使用的功能并不依赖于员工完成其工作。它更方便了WCF服务提供的功能。此外，为此服务构建此类逻辑将允许在非IIS托管环境中更容易地进行服务修改。
此外，有没有办法在服务上构建逻辑，以便当我下载客户端的代理代码时，如果ServiceHost不可用，它只知道手动访问数据库？如果这是可能的话，我认为我所有问题的90％都会消失。
提前谢谢！
答案 0 :(得分：1)
根据您的描述，听起来保持现有的DLL，即直接访问数据库，最适合您的需求。拥有WCF服务不会增加任何内容，如果它失败时，你只会使用DLL。
理想情况下，您将完全使用WCF服务并提供某种冗余以处理任何潜在的服务问题。此外，使用服务意味着您不必处理任何DLL升级/部署。
但是，从你的问题来看，如果服务不可用，听起来会有一些真正的问题需要处理，所以只需要使用DLL。
编辑：请阅读问题的最后部分，我认为不可能。添加对项目的引用时，将生成用于访问服务的代理代码。您所追求的那种“动态”信息实际上需要一项服务。
编辑：作为我下面评论的后续内容，您可以通过创建DLL和类来测试它，我们称之为Class1。然后使用将返回Class1的方法创建WCF服务。创建客户端应用程序并添加对服务的引用。如果你看看代理生成的代码，你应该看到（希望......我正在考虑这个，因为我输入:)）该方法返回Class1，但是当你编译它时将无法找到Class1。这是因为Class1没有DataContractAttribute，它会在客户端上自动生成Class1。因此，您必须将共享DLL分发到客户端。现在，当方法返回并且WCF尝试重新创建Class1时，它将使用共享DLL中的本地版本。您的其他DLL（已经在客户端上）将使用相同的共享DLL。