WCF数据边界设计

Question

这更像是一个设计问题：

假设我有一些内部类型定义，我绝对想要保密（不向我的服务消费者公开。但是，我确实需要与服务用户交换数据。我想与之分享一些类型用户与内部用户完全相同，而其他用户是内部类型的简化版本。相同或不同的对象 - 我主要担心的是内部对象永远不会暴露给外部世界，我的第二个问题是现在做得太多了重复代码...

我的想法是，我真的不希望出现错误地将内部对象暴露给WCF的情况（对于内部对象，我甚至没有将其标记为 [DataContract] < / strong>），所以我考虑了以下方法：

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

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

这是正确的做法吗？是否有任何已知的模式可以更好地解决上述问题？

非常感谢， 奥弗

Answer 1

制作两种类型。重复的代码很糟糕，是的，但让你的内部数据与你的DTO不同并在它们之间进行转换是很常见的。

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

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

Answer 2

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

• 你不想暴露所有的实现，但可能只是一个子集。这是您描述的场景。
• 您已经为要用于服务实施的域找到了更好的抽象，但对于您的服务用户而言，这很难理解。

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

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

此外，您还可以识别可以由服务执行的数据操作，而不是将数据移动到服务客户端并返回到服务。这样你就可以避免这个问题。

祝你好运！