C# 通用WCF对象支持类

在涉及WCF的服务器和客户端项目中，我不知道如何添加/包括/引用一组所需的支持类

在我的C#解决方案中，我有：

• 做服务器类型工作的服务器项目
• 一个做gui类型工作的客户机项目
• 包含网络传递数据对象的类定义的WCF库

服务器项目使用普通引用包含WCF库。客户端项目使用对WCF库的服务引用

---

我的问题是，在使用WCF库中包含的对象定义的服务器和客户端项目中，我都需要一些实用程序类。我不想在服务器和客户机项目中放置两个（相同的）这些类的副本——我更希望只保留一个副本。这会建议使用类库，但是引用是如何工作的呢？这个新类库将有一个对WCF库的标准引用，然后服务器和客户端项目都必须依次标准引用这个新类库。但是，客户机项目现在对WCF库中包含的数据对象类不是有两种不同定义的定义吗？还应该如何包括这些实用程序类呢？

使用服务引用方法消除了使用WCF的一些最初的麻烦，因为它为您生成的代码简化了您在早期WCF时代的生活。然而，随着您越来越习惯于使用WCF，并且意识到服务引用实际上在做什么，您开始意识到服务引用方法有时更像是一种障碍而不是帮助

例如，在我的例子中，我有一个WCF服务，它被三个不同的项目使用——两个C项目和一个托管C++项目。每次更新WCF服务接口时，我都必须在这三个项目中重新生成服务引用。这很快就让我头疼

此外（您正在遇到这种情况），服务引用方法只处理DataContract类的结构，而不是它们的行为。因此，如果在服务器端向DataContract类添加方便方法，则必须在客户端手动添加该行为，因为它不是通过元数据交换（MEX）操作传递的

就在那时我偶然发现了这个。在这本书中，Miguel Castro提出了一个令人信服的理由，即完全避免使用服务引用方法。当你审视他的论点时，它真的很有意义

根据他的建议，我建议将您的DataContract类和在其上操作的类放在一个由客户机和服务器直接引用（无服务引用）的类库中。正如您将从视频中看到的，自己编写客户端代码并在WCF接口更改时进行更新非常简单

我已经使用这个方法几个月了，我发现这个解决方案比使用服务引用方法更灵活