设置WCF服务项目和应用程序的最常见/最佳方法是什么？
以下是一个例子：
我的问题是将合同和实现拆分成单独的DLL是否合理，以及应用程序是否应该引用Common / Impl库，或者应用程序是否只应该提供服务引用（使用“创建服务引用”或SvcUtil）。我认为应用程序仅提供服务参考可能是有意义的，因此您不会将Common / Impl与应用程序结合起来。在这种情况下，在MyService.Impl中创建客户端类是否有意义？
答案 0 :(得分：5)
查看Web Service Software Factory。它为构建WCF应用程序提供了很多很好的指导，包括对solution structure的一些指导。此外，IDesign.NET（Juval Lowy）也有一些guidance on that（zip链接）。
答案 1 :(得分：1)
如果您使用的是复杂类型，则应在客户端应用程序中包含服务接口和公共类，否则生成的代理将复制您在服务中使用的类型的定义，并且可能会导致您在以后进行序列化时感到头痛。 ..
然后，您可以手动生成使用通用程序集中的类型的代理，而不会重新创建模拟您的类型的其他类。
C：\ Samples \ WcfSerialization＆gt; svcutil.exe /out:WcfServiceProxy.cs / d：Schmu rgon.WcfClient.Web /r:Schmurgon.Data.Contracts\Schmurgon.Data.Contracts\bin\debu g \ Schmurgon.Data.Contracts.dll http://localhost:5150/Schmurgon.WcfService.Host/S ervice.svc？WSDL
开关是：
/ out：param只是输出代理类的名称。
/ d：存储代理类的目录。
/ r：包含否则将包含在代理类
中的类型的程序集[none]您的WCF服务的地址。
（这是从http://schmurgon.net/blogs/ben/archive/2006/12/17/wcf-proxy-generation-without-types.aspx粘贴的）
答案 2 :(得分：1)
取决于。
通常，生成的代理类足以让客户端程序调用WCF服务，因此不需要客户端库。当然，在某些情况下，例如，如果您的合同仅指定Message作为其参数，并且您在引擎盖下使用数据合同，但这些非常罕见！
我不会做的是将客户端类（如果您认为需要）放在与服务实现相同的库中 - 客户端不需要知道服务是如何实现的，只是如何调用服务。通过将两者放在一起，您也可以分发服务实现。
如果您使用数据合同标记您使用的类，那么Hugo提到的复杂类型问题将不会发生，您应该这样做以便轻松版本化服务。
答案 3 :(得分：1)
我的问题是将合同和实现拆分成单独的DLL是否合理，以及应用程序是否应该引用Common / Impl库，或者应用程序是否只应该提供服务引用（使用“创建服务引用”或SvcUtil）。我认为应用程序仅提供服务参考可能是有意义的，因此您不会将Common / Impl与应用程序结合起来。在这种情况下，在MyService.Impl中创建客户端类是否有意义？
宾果 - 你“得到了”它！即使从理论上讲，技术上可以使用共享程序集共享契约和接口，我宁愿不建议。首先，其他客户端（例如Java，PHP，Ruby）将无法使用共享的.NET程序集。所以他们突然使用与客户端不同的界面，这可能会导致微妙的变化，这可能很难调试。
其次，SOA就是将系统的各个部分分离成具有明确定义的服务边界的独立，不同的实体。共享程序集引入了您试图避免的依赖项。
因此，我会同意你走在正确的轨道上 - 是否将合同接口与其具体实施分开是可以辩论的。一个好处可能是您需要创建相同接口的第二个，第三个实现，或者如果您在各种服务使用的单独程序集中有某些常用的帮助程序接口。还有一个组装并没有真正受到伤害 - 我的建议是完全按照你在帖子中列出的那样做！马克