Reputation: 607
I've been reading about having a [DataContract] specified class in my Silverlight project. I know they get serialized and passed to the client to pass information.
In addition to this, it seems you can add code to these classes in certain situations. Now the book I'm reading gives the example which is a Silverlight application and the hosting web project. This isn't like my project, because I have a separate WCF service which is hosted though IIS. It's not all in the same solution. I wish to have a Datacontact class with shared code between my application and this WCF service.
I already have the [DataConract] class set up and all, and it can pass fine between the WCF service and the application. I just wanted to know if doing it this way rather than having it all in the one solution prohibits me from adding code inside the [DataContract] class.
Okay, thanks for reading.
Upvotes: 2
Views: 564
Reputation: 31444
In most cases you want to avoid any logic in data contract classes. Clients created by referencing web service are unable to generate any of the custom methods you may be using on server side.
Of course, that doesn't prohibit you from putting logic in those classes. It's just that it won't be available at client side.
Instead, you can create shared library which will be used on both client and server side, and put classes responsible for data contract manipulation/business logic there. In case you follow that route, you may want to take a look at Portable Class Library - which allows you to create assemblies that can be used both on server-side end as well as Silverlight client end.
Another option is to link data contract classes from server project to Silverlight client project. You can do that from Visual Studio using Add -> Existing Item -> Add As Link option. This will also allow you to share code between server and client, however it might get quite messy at times (considering Silverlight limitations).
Upvotes: 4