views:

46

answers:

1

We are starting to build a common entity model using Entity Framework v1. The goal is to expose various common operations as services that can be used by several different clients. The problem we are running into is reusing the types across multiple services. Example:

Service1 (at http://example/service1/service.svc) returns a List

Service2 (at http://example/service2/service.svc) returns a Review object which has reference to a Product object.

I would like to reference both of these services in my client apps (typically Silverlight) but have the Product type from both services be the same. How do I go about doing this?

+1  A: 

Sounds like a common library with interfaces/datacontracts is what is needed.

It would contain IProduct/IProductDataContract which your services should return.

This would then be shared across all three. The concrete implementation woul dthen be down to each services, just as long as they conform to the data contract/interface.

MattC
This seems like a lot of work, and seems to defeat the purpose of a lot of the proxy generation stuff that is build into VS. In a lot of cases this seems like overkill. However, according to these two article, creating a client side copy of the class seems to be the approach to take http://compiledexperience.com/blog/posts/Resuing-types-in-Silverlight-Service-Referenceshttp://inquisitorjax.blogspot.com/2008/07/silverlight-2-sharing-code-between.html
Jacob Adams
Well th egeneric proxy generation in VS is not the quickest, due to the creation of a ChannelFactory each time you make a call. And yes it is more work. From my perspective I think I liked interface driven approach (i.e., seperate lib) as it allows me to remove the dependancy/visibility of WCF in the system. If all my client apps know is they query a factory clas sthat returns and interface they never know WCF is doing to work. Just allows for replacement of stubs and mock object and even service layer communication easier to replace.
MattC