我们正在讨论有关使用WCF以及创建服务和客户端支持的问题。
目前，我们通过提供服务库客户端的Silverlight版本来支持Silverlight客户端，以便我们可以保持使用接口定义的服务合同的强类型。
这没关系，但是使用接口定义服务会让其他客户端变得尴尬，因为WSDL有很多方法返回ArrayOfAnyType，而且一切都只是客户端的对象（可以转换为正确的类型，但是正如我所说，它的尴尬）。
我们可以重写我们的服务，使用显式DTO进行消息传输，并使用类似的客户端库重新创建业务对象，这将使我们的服务更具互操作性。
这样做似乎会阻止我们的一些选项，例如使用EntityFramework和它提供的自我跟踪实体，因为这些需要在客户端和服务器上共享相同的库并且不可互操作（如果我'，请纠正我我错了）
似乎可以在互操作性和开箱即用的更多功能之间进行权衡，从而可以更快地开发解决方案。
所以我的问题是我们通过决定不可互操作并且只支持.net和silverlight客户端（如果支持Silverlight客户端可以被认为是不可互操作的）获得了什么优势？什么有用的.net功能，我们通过决定可互操作来阻止自己？
是否存在允许两种类型的解决方案共存的标准技术，因此您可以使用可用的全部功能支持.net客户端，但仍能很好地支持其他非.net客户端？
答案 0 :(得分：0)
您可以使用Facade Pattern。
将当前逻辑移至业务层，不要通过WCF公开它。
现在为您希望支持的每个合同创建一个WCF服务。该层将业务层对象映射到合同对象，并在业务层中调用功能。
然后，您可以为每个客户端提供所有逻辑和自定义服务的中心位置。