在WCF中拥有不可互操作的服务的优势？

Question

我们正在讨论WCF的使用以及服务和客户端支持的创建。

目前，我们通过提供我们服务库客户端的silverlight版本来支持silverlight客户端，这样我们就可以保持使用接口定义的服务契约的强类型。

这是可以的，但是使用接口定义服务会让其他客户端感到尴尬，因为WSDL有很多返回ArrayOfAnyType的方法，客户端的所有东西都是对象(可以转换为正确的类型，但正如我所说的，这很尴尬)。

我们可以重写我们的服务以使用显式DTO进行消息传输，并使用类似的客户端库重新创建业务对象，这将使我们的服务更具互操作性。

然而，这样做似乎会阻碍我们的一些选择，比如使用EntityFramework和它提供的自我跟踪实体，因为这些需要在客户端和服务器上共享相同的库，并且不能互操作(如果我错了，请纠正我)

似乎在可互操作和获得更多开箱即用的功能之间存在权衡，允许更快地开发解决方案。

所以我的问题是，如果我们决定不能互操作，并且只支持.net和silverlight客户端(如果支持silverlight客户端可以被认为是不可互操作的)，我们能获得什么好处？又有哪些有用的.net特性是我们通过决定实现互操作来阻止自己的呢？

是否有允许这两种类型的解决方案共存的标准技术，以便您可以使用所有可用的功能来支持.net客户端，同时仍然很好地支持其他非.net客户端？

Answer 1

为此，您可以使用Facade模式。

将当前逻辑移动到业务层，不要通过WCF公开它。

现在创建两个WCF服务，每个服务用于您希望支持的每个契约。这一层将业务层对象映射到契约对象，并调用业务层中的功能。

这样，您就可以为每个客户端的所有逻辑和自定义服务提供一个中心位置。