Silverlight Model mapping and Repository pattern question

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 chan开发者_开发技巧ges 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!

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.