WCF数据边界设计

Question

这更是一个设计问题：

可以说，我有我绝对要保密的一些内部类型定义（不暴露我的服务消费者。然而，我确实需要交流。数据与服务用户，我想与用户分享的一些类型与内部类型完全一样，而另一些类型是内部类型的简化版本。是否相同对象 - 我主要关心的是内部对象将永远不会暴露在外面的世界，我的第二个担心是现在使太多重复代码...

这个想法是，我真的不想有内部对象的情况被错误地暴露在WCF（这只是发生在我身上的，甚至没有被标记为[DataContract]内部对象），所以我想到了以下方法：

1. 设计我WCF服务合同文件没有任何引用内部类型命名空间。 - 这将提供更好的安全性。

2. 在服务实现代码上实现内部类型及其相应公共代表对象之间的转换。

这是正确的做法吗？有没有更好的解决上述问题的已知模式？

非常感谢， 奥弗

Answer 1

使两种类型。重复的代码很糟糕，是的，但是让你的内部数据和你的DTO不同，并且在它们之间进行翻译是很常见的。

就我个人而言，我认为这几乎是一种最佳做法。

此外，请考虑您的合同，以及是否需要发送整个数据对象或是否只需发出远程命令。

Answer 2

首先，我想再次向您保证，与服务级别模型相比，在服务实现中有不同的模型是完全可以的。有几个原因会导致这种情况发生和/或有用，其中两个是：

• 您不想公开所有实现，但可能只是一个子集。这是你正在描述的场景。
• 您已经找到了一个更好的抽象概念，您希望用于您的服务实现，但对于您的服务的用户来说这太难理解了。

这两个原因在我的经验是有效的，都提供了价值。通过我的团队，我经常将用作服务级别的模型称为“服务级别域模型”。我相信还有其他更好的名字。

使您不想公开的所有类型（接口，类，结构，枚举）实现它们的程序集。然后创建重复 - 这些可能是DTO（数据传输对象）或其他 - 您想要展示的作品，但仅复制数据，而不是实施。取决于实现，您可以使用一些基于反射的巫术来在内部和外部表示之间交换数据。注意可能的性能影响。复制数据是有代价的。

另外，您也可以将数据移到服务客户端并返回到服务，而不是将数据移动到服务可以执行的操作上。这样，你首先避免了这个问题。

祝你好运！