首先抱歉我的英语不好！ 我在许多Silverlight教程中看到以下内容：
我们在服务器端有模型，例如Product。 webservice有一个方法，例如Ilist GetProducts（）; 在客户端，我们添加服务引用时生成的Product类。然后我们将在viewmodels和xaml中使用此Product模型。 但是，如果有人在服务器端进行更改或者产品模式更改（例如“Name”属性）将是“NameProperty”或任何人尝试将Web服务更改为其他人，会发生什么。 Product代理类也将在客户端更改，然后我们必须“刷新”使用Product类的视图模型和绑定等。
这个解决方案怎么样？：
在Silverlight端，我有一个IProduct接口，它包含viewmodels和xaml将使用的所有属性。 我创建了一个具有IList GetProducts（）方法的IRepository接口。我实现了这个接口，例如WCFRepository，它从wcf服务获取数据。 GetProduct方法的实现将所有Products映射到IProduct的实现，只需将属性复制到IProduct的实现。因此，当服务器端的产品发生更改时，我只需要更改WCFRepository上的映射。或者，如果我将WCF服务更改为其他服务，我只需要在GetProducts方法的实现中编写OtherRepository和write映射。 在此解决方案中，视图和视图模型不会更改！
我的解决方案怎么样？我正朝着正确的方向前进？有没有关于这个的好样本，教程，模式？任何关键字都会很好！ :)谢谢！
答案 0 :(得分：0)
一般来说，我认为你的想法比坏事好。首先，你说你的服务接口是不稳定的，如果它发生了变化。好吧，如果您的应用程序和服务是单个程序进程的一部分，那么奇怪的是有人想要更改您的服务属性名称而不是修复应用程序，因为它们将被捆绑在一起。
您的方法看起来像链中必须维护的不必要的链接，并且通常是您的真实服务的代理。目标是提供一个“常量”（如果你需要更改你的存储库界面，我认为它需要的概率非常接近你的默认服务所需的变化的概率，你不会赢得任何因为应用程序必须是无论如何重新映射）部分服务完整界面..但我相信，如果服务接口将开始包含比存储库服务更多的功能，您将不得不移动它们并在其中复制镜像功能。
所以一般来说，你不会受益太多但是必须经常在服务器端做X2工作。