views:

698

answers:

3

I have a custom data entity (data object) that is exposed via a WCF webservice. The WCF service lives in a web application. I then have a Silverlight application with a service reference to that WCF service. When i add the service reference a proxy is generated, and that includes a version of the custom data entity.

How should i structure my code so that the data entity is declared in one place, and shared amongst the project containing the WCF service and any Silverlight applications that reference it? I want to eliminate the version of the data entity that is generated with the proxy.

Thanks :)

+1  A: 

I´m not quite shure why anybody want to do that. You have to understand that the type you find in the proxy is a projection of the Type you have at Service server site. It´s defined in the *.g.cs files and gets generated new if you update the service reference. In my opinion it´s the best way to have it declared in a single location, and project it. You need it in two places and it´s single defined.

I may be wrong anyway .....

Ren Hoek
There are several reasons why the generated proxy version of the data object can suck. In my case, i want to use the same data objects in different versions of the UI. It is quite a common approach, but in this case is made more difficult by the fact that a Silverlight app cannot reference a non-silverlight assembly. Even if you work round that by referencing files between projects it can be cludgy, you can end up with namespace issues, it isn't really truly referencing one definition of the data object.
slugster
+1  A: 

Declare the data entities in the WCF service or a project that the service refereneces, then from the Silverlight project add the entities as links and make sure the "Reuse types in referenced assemblies" checkbox is selected from the Service Reference Settings dialog.

You can put the types in either the Silverlight or WCF side.

I have tried doing things this way and found that using DTOs instead and mapping them to the entities in the Silverlight side to be much cleaner and easier to work with although I did write a bunch of mapping code to get the DTOs into the entities and vice versa.

DaveB
Thanks Dave, having the mapping code in place was what i did until i managed to get the Reuse functionality to work as it should (as per the post marked as the answer). The mapping code was a good work around, but a PITA as the objects were identical but just in different namespaces.For anyone that is curious on how i did the mapping, i extended the partial classes and included a new constructor that took an instance of the object to be mapped:MyProxyDataObject = new MyProxyDataObject(mySharedObject)and so on.
slugster
This mapping technique is great if the WCF and Silverlight objects don't exactly match each other. The main hassle is having to use full namespaces when you are casting values from one object to the other (like enums) (i didn't have to use full namespaces all the time, but if i didn't then it would of lead to confusion later when some other developer had to look at the code).
slugster
+2  A: 

There is a good example of how to do this here by Pete Brown. Using that approach you can use the same classes in both the Silverlight client and in the WCF service without having to use the generated objects.

Bryant
This is what i tried to do, but getting it to work was intermittent. Weird behaviour from VS - i had the "Reuse..." checkbox ticked, and every time i either recreated or updated the service reference it would still generate the items in the proxy. Then i made a tiny tweak to one of the shared objects, updated the service reference again, and it just worked... weird. I then had to comment out all my mapping code that i had put in because of this behaviour.
slugster