What you are referring to is to having business logic in both the client and server code, which is normally not a good solution. Sure, a simple property calculation like the one mention above might me ok, but since you are talking about a proof of concept I assume the real business logic is going to be much more advanced. If so, keep try keeping the logic on the server side (accessing these methods as public wcf services instead)
For smaller stuff (again, like the example above) there might be times when you need it both on client and server side. If so, you can use partial classes (just like you suggested). You cannot reuse assemblies across silverlight/wcf since the frameworks differ.
During PDC this year, some MS guy talked about the future of silverlight, where he showed an example of a future toolkit that allows us to write stuff on the server side, which is automaticallty transformed to silverlight code. Pretty cool, but not available right now.
Then again, in a real life scenario, there are very few occasions where you need shared server/client code, so keeping the business logic on the server side should be enough in most cases.
Main Topics
Browse All Topics





by: apeterPosted on 2008-12-23 at 06:38:25ID: 23233785
1. Make sure , they are public methods.
.com/2008/ 06/tutoria l-creating -wcf- servi ce-for.asp x
2. When ever u make chages in your Windows service, update your service reference in your client application.
Hope below link helps u in tutorial
http://www.jeffblankenburg