Silverlight模型映射和存储库模式问题
首先抱歉我的英语不好！ 我在许多 Silverlight 教程中看到以下内容：
我们在服务器端有模型，例如产品。 Web 服务有一个方法，例如 Ilist GetProducts()； 在客户端添加服务引用时生成的产品类。然后我们将在 viewmodels 和 xaml 中使用这个 Product 模型。 但是，如果有人在服务器端进行更改或产品模型更改，例如“Name”属性将变为“NameProperty”，或者任何人尝试将 Web 服务更改为其他服务，会发生什么情况。 Product 代理类也会在客户端发生变化，然后我们必须“刷新”使用 Product 类的视图模型和绑定等。
这个解决方案怎么样？：
在 Silverlight 端，我有一个 IProduct 接口，其中包含视图模型和 xaml 将使用的所有属性。 我创建了一个 IRepository 接口，它有一个 IList GetProducts() 方法。我实现了这个接口，例如 WCFRepository，它从 wcf 服务获取数据。 GetProduct方法的实现会将所有Products映射到IProduct的实现，只需将属性复制到IProduct的实现即可。因此，当服务器端的产品发生更改时，我只需更改 WCFRepository 上的映射即可。或者，如果我将 WCF 服务更改为其他服务，我只需编写 OtherRepository 并在 GetProducts 方法的实现中编写映射。 在此解决方案中，视图和视图模型不会改变！
我的解决方案呢？我正朝着正确的方向前进吗？有什么好的示例、教程、模式吗？任何关键词都可以！ ：） 谢谢！
First of all sorry my bad English!
I see in many Silverlight tutorials the following:
We have models on the server side for example Product. The webservice has a method for example Ilist GetProducts();
On the client side Product class generated when we add service reference. Then we will use this Product model in viewmodels and xaml.
But what happen if anybody make changes on the server side or the Product modell change for example „Name” property will be „NameProperty” or anybody try to change the webservice to an other. The Product proxy class will also change on the client side, then We have to „refresh” viewmodels and bindings etc, which use the Product class.
What about this solution?:
On the Silverlight side I have an IProduct interface, which contains all property that the viewmodels and xaml will use.
I make an IRepository interface which has an IList GetProducts() method. I implement this interface for example WCFRepository which get data from a wcf service. The implementation of GetProduct method will map all Products to an implementation of IProduct, just copy the properties to the implementation of IProduct. So when the Product on the server side change I only have to change the mapping on the WCFRepository. Or if I change the WCF service to an other service I only have to write OtherRepository and write mapping in the implementation of the GetProducts method.
In this solution the view and viewmodels not change!
What about my solution? I am going to the right direction? Is there any good sample, tutorial, pattern about this? Any keyword will be good! :) Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，我认为你的想法坏多于好。首先你说你的服务接口不稳定，万一变了怎么办。好吧，如果您的应用程序和服务是单个程序进程的一部分，那么有人想要更改您的服务属性名称而不是修复应用程序，这很奇怪，因为它们将被捆绑在一起。
您的方法看起来像是必须维护的链条中不必要的环节，并且通常是您真实服务的代理。目标是提供一个“常量”（如果您需要更改存储库接口怎么办，我认为需要它的概率非常接近默认服务中所需更改的概率，并且您不会赢得任何东西，因为应用程序必须但我相信，如果服务接口将开始包含比存储库服务更多的功能，您将必须移动它们并在其中复制镜像功能。
因此，通常您不会受益太多，但必须经常在服务器端执行 X2 工作。
Generally I think your idea is more bad than good. First of all you say that interface of your service is unstable, what if it changes. Well if your application and service are part of single program process its strange that someone would want to change your service property name and not fix application cause they will be tied together.
Your approach looks like an unnecessary link in the chain that will have to be maintained, and would be generally a proxy to your real service. Goal is to provide a "constant" (what if you need to change your repository interface, I think probability that it will be required is super close to probability of required change in your default service and you wont win anything cause application will have to be remapped anyway) part of your service full interface.. But I believe that if service interface will begin to contain more functions than your repository service you will have to move them and replicate mirror functions in it.
So generally you wont benefit much but would have to do X2 job often times on server side.