views:

3061

answers:

4

My project is split up into a typical 3 layer structure for a Silverlight app. That is:

  • A base layer, which is a class library that contains all my business objects, logic, data access etc.
  • A middle layer which is a WCF service which communicates with;
  • My Silverlight front end

The problem I have is that currently the BO's exposed through WCF to my UI only contain the private variables, and none of the propertys or methods.

Is there an easy way to expose the full object (via attributes or configuration)?

What is the best solution?

+1  A: 

I did something similar on a small project by creating a "communication layer" dll, which contained only the objects being passed between client and server. A variation of this (share a dll between all the projects needing these objects) should work for you. Watch out for versioning issues, though. Unless you have full control of both ends, an upgrade to one end could cause headaches, if you're not careful.

+8  A: 

It seems that you are expecting internal classes used in the WCF service which you have marked as DataContracts to be exported as .NET objects to your client code (the Silverlight UI). WCF does not support this capability. A class marked as a DataContract is just that, a data structure with no methods. If you need a good resource for undestanding WCF, try Learning WCF: A Hands-on Guide by Michele Bustamente.

@John Fisher does sketch out a way of exposing .NET objects to both the client & service but this may not be an option for Silverlight. Here is a blog entry explaining how to access REST-based services from Silverlight.

Sixto Saez
So you're saying I need to create proxy objects with DataContract attributes? And fill these objects with my BO's from the class library?
jacko
Visual Studio generates the proxy for a WCF service by adding a Service References to the project. Code is generated that will create classes to represent the DataContracts and methods to represent your OperationContract. A WCF service is designed to deliberately hide the internal service objects.
Sixto Saez
Yeh don't worry. I have it now. I wasn't using datacontracts to begin with, just the proxy classes WCF was auto-generating. But I've added them in properly which is a better solution. Thanks
jacko
+1  A: 

Sixto's answer is correct. With WCF you can share the BO DLL between the client and the service and re-use those objects (just configure the WCF service reference this way), but this won't work in your case. The issue is that your BO project is a standard .NET project and not a silverlight project.

Typically I structure my projects a little differently than yours:

  • Common Objects - these would be the data structures marked up with WCF attributes and would also contain any common interfaces such as my data layer interface.
  • Data Access - any data access objects. This references only the common objects and returns those from data calls.
  • Business Logic (optional) - If there are other web services to interface with stick that in its own layer
  • Service - The actual WCF service, references Common directly and other projects through interfaces
  • Silverlight - references the Service

If you moved your business logic out to its project and just referenced your common "dumb" objects, then you could probably create two logic projects, one silverlight and one standard, and just have the actual files in one and create links to those files in the other. That way you would get the same logic across both projects and it would exist in both Silverlight and standard .NET.

Bryant
+1  A: 

Mark up your objects that are being used by the service with [DataContract] attributes and then put [DataMember] on the public properties. This will solve your problem.

jezell