Linq to Entities with WCF

Question

Hi there,

I have all my entities in a seperate project in my edmx file and I expose them to my client application using a WCF service.

That means I don't have to give my client app a direct link to the project that contains the edmx file. That would be bad because it contines the object to query the database with.

But only the entities that my WCF service uses can be accessed from my client app. So for example because I have the following code in my service:

public MyClass GetMyClass()
{
     return new MyClass();
}

.. I can use access MyClass in my client app with something like:

myServiceInstance.MyClass cls = new  myServiceInstance.MyClass()

What about if I have an entity called MyClass2 in my edmx file that I want to use in my client app! How to I instansiate it without giving my client a direct link to my edmx file project or making a usless method in my service layer that returns MyClass2

What are other people doing?

Thanks a lot

Answer 1

If the WCF service doesn't use it, what would you want it for? A WCF service (itself) is purely for data transport - the "mex" approach for metadata doesn't share code, so your MyClass2 would be impotent. If you want, you can use assembly sharing at the client, but I really don't recommend this in this case; EF objects at the client is a mess... (plus it won't work on the lightweight frameworks like Silverlight, Client Profile, Compact Framework, etc)

Another option is ADO.NET Data Services; this works over WCF, but gives you a more LINQ-friendly API than the regular WCF approach - and any domain objects that your model exposes should be available on the client data-context.

Answer 2

We created a separate project with Domain Transfer Object Classes that served as Data Contracts for our various internal WCF services. We then shared the contracts project with those internal services. We had one data service; those methods would translate these domain objects to/from entity objects before/after storing/retrieving. Meanwhile, the external services made use of the standard proxies generated from XSD and WSDL files, and translated to/from the shared domain transfer model.

We had to do this because the object context is not (yet) portable over WCF, unfortunately.

Some considerations for your situation:

1. If your client app is external to your system, it should not know anything about your EDMX or its classes. It should only know about your WSDL and XSD.
2. If your client app is internal, then it is no use trying to share the entity classes in EF v1 because it is not supported properly, yet. You need to transfer more than just the classes/objects - you need the context too, which maintains change tracking, and it cannot be done via WCF directly right now.

Answer 3

Hi Marc, If I had for example this method in my WCF service: public Customer GetCustomer() { //Return a customer } Then in my client I could instantiate a Customer object by doing: myServiceInstance.Customer cus = new myServiceInstance.Customer()

But if I have only the following method defined in my service: public void SaveCustomer(Customer cus) { //Do work } Then I can't say myServiceInstance.Customer because my service does not have it in it's reference list. So in my client how can i instantiate a customer object without having a reference to the project containing my edmx file?

And hurst, for what you said. That is certainly a solution but I would like to avoid having to "translate domain objects to/from entity objects" every time. I would like to use the entity objects directly through a WCF service.

I'm appreciating the help guys

Answer 4

If you want to do it the "proper" way, you should be creating special classes for your messages that are going across the wire, rather than trying to reuse business entities or data objects as messages. The value in this is that you are then free to change your business entities and data objects without worrying about the contract you have exposed to consumers changing. Every change to your service is a bit more deliberate since it happens independently of changes to data and business logic.

Another way to handle this is simply to use svcutil (or "Add service reference..." though svcutil works better for multiple service endpoints) to generate all the classes that the client will be using instead of adding a reference to the server project. That way, the only classes your client will ever see are the ones exposed by the service.