正如主题行所描述的，我正在将C＃库公开为WCF服务。最终我们想要公开所有功能，但目前范围仅限于库API的子集。本练习的目标之一是确保WCF服务使用请求/响应消息交换模式。所以接口/ API将会改变，因为现有的库不会使用这种模式将库转换为WCF Web服务
我已经开始实施服务合同和请求/响应对象，但是当涉及到设计DataContracts时，我不确定哪个要走的路。 我分离回去并用DataContract/DataMember属性注释现有的库类VS定义新的类，它们就像现有类的代理类一样。
有没有人有类似的任务经验或有任何建议，哪种方式效果最好？我想指出，我们的团队拥有现有的库，因此有它的源代码。任何指针或最佳做法将有所帮助
我的建议是使用适配器模式，在这种情况下基本上意味着创建全新的DataContracts和ServiceContracts。这将允许所有内容独立变化，并允许您优化WCF的WCF和API的API（如果有意义的话）。你想要做的最后一件事是沿着修改路线走下去，发现一旦你几乎完成了某件事就不会映射到正确的位置。
谢谢Ethan。我其实是这样做的。我定义了定义服务和数据合同的全新类别 – CodeKata 2011-06-18 04:43:20
从.NET 3.5 SP1开始，您不再需要使用[DataContract]/[DataMember]属性修饰要公开的对象。所有的公共财产将被自动暴露。这就是说，我个人更喜欢使用特殊的DTO对象，并使用这些属性进行公开和装饰。然后我使用AutoMapper来映射实际域模型和我想要公开的对象。
谢谢Darin。我同意你的看法，尽管我对图书馆不熟悉，所以避免使用Automapper。我也担心在我的生产环境中使用它，因为我不知道它是如何被测试的。我不知道Automapper是否能很好地与Unity协同工作。 – CodeKata 2011-06-18 04:45:17
如果您要继续使用现有的库，但想要控制作为Web服务API公开的内容，我建议将新类作为封装器定义在库上。
我的意思是说，即使您认为您不打算继续在其他环境中使用它，也不要“转换”现有的库。如果它已经过测试和证明，那么请利用这一事实并绕过它。
谢谢戴夫。所有3个答案都有相同的主题，我很高兴我的方法没有什么不同。感谢您的反馈意见 – CodeKata 2011-06-18 04:46:04
记住要考虑是否要使用肥皂或休息或两者兼而有之。这将对您的合同设计产生影响。看看最近发布的Microsoft Web API。 – 2011-06-16 19:45:45