Silverlight 模型映射和存储库模式问题

Question

首先对不起我的英语不好！ 我在许多 Silverlight 教程中看到以下内容：

我们在服务器端有模型，例如 Product。该网络服务有一个方法，例如 Ilist GetProducts(); 在我们添加服务引用时生成的客户端产品类。然后我们将在 viewmodels 和 xaml 中使用这个 Product 模型。 但是，如果有人在服务器端进行更改或产品模型更改（例如“Name”属性将是“NameProperty”）或任何人尝试将 Web 服务更改为另一个，会发生什么情况。 Product 代理类也会在客户端发生变化，然后我们必须“刷新”使用 Product 类的视图模型和绑定等。

这个解决方案怎么样？：

在 Silverlight 方面，我有一个 IProduct 接口，其中包含视图模型和 xaml 将使用的所有属性。 我创建了一个具有 IList GetProducts() 方法的 IRepository 接口。我实现了这个接口，例如从 wcf 服务获取数据的 WCFRepository。 GetProduct 方法的实现会将所有产品映射到 IProduct 的实现，只需将属性复制到 IProduct 的实现即可。因此，当服务器端的产品更改时，我只需要更改 WCFRepository 上的映射。或者，如果我将 WCF 服务更改为其他服务，我只需编写 OtherRepository 并在 GetProducts 方法的实现中编写映射。 在这个解决方案中，视图和视图模型不会改变！

我的解决方案呢？我要去正确的方向吗？有没有关于这个的好的示例、教程、模式？任何关键字都会很好！ :) 谢谢！

Answer 1

一般来说，我认为你的想法是坏的多于好的。首先你说你的服务接口不稳定，如果改变了怎么办。好吧，如果您的应用程序和服务是单个程序进程的一部分，那么有人会想要更改您的服务属性名称而不是修复应用程序，因为它们会被捆绑在一起，这很奇怪。

您的方法看起来像是链条中一个必须维护的不必要的链接，并且通常是您实际服务的代理。目标是提供一个“常量”（如果您需要更改存储库接口怎么办，我认为需要它的概率非常接近默认服务中需要更改的概率，并且您不会赢得任何东西，因为应用程序必须是无论如何重新映射）您的服务完整接口的一部分。但我相信，如果服务接口将开始包含比您的存储库服务更多的功能，您将不得不移动它们并在其中复制镜像功能。

所以通常你不会受益太多，但必须经常在服务器端做 X2 工作。