WCF Problem with Proxy Class vs. Real Class

Question

Hi,

I have a WCF service that my console application consumes. The proxy class is generated which uses the console application namespace.

The DataAccess layer has a method GetItems which requires a ITEM object which belongs to a different namespace. Is there anyway to tell WCF to create the items which belong in a certain namespace and not use the client project to create the namespace!

UPDATE

Here is the problem:

// The following namespace belongs in the class library project 
MYProject.Something.Foo foo = new Foo(); 
foo.Text = "hello world"; 

// Now the webservice has a method ProcessFoo but the proxy 
// class shows something like this: 
ProcessFoo(MyClientProject.Something.foo);

I cannot send my MYProject.Something.Foo to ProcessFoo method.

Answer 1

UPDATE

Turns out that I completely mis-understood your original question. You can either manually copy the properties of your MYProject.Something.foo object to MyClientProject.Something.foo or, if it's an operation you'll use frequently, you can implement some sort of conversion routine so that you could do:

MYProject.Something.Foo foo = new Foo(); 
foo.Text = "hello world"; 

ProcessFoo((MyClientProject.Something.foo)foo);

ORIGINAL

Any time you create an object, you can always use its full name to specify namespace:

SqlConnection conn = new SqlConnect();

is equivalent to

System.Data.SqlClient.SqlConnection conn = 
    new System.Data.SqlClient.SqlConnection();

Answer 2

You can alias classes using the import statement, avoiding naming collisions:

import MyProject; // MyProject.Something
import ServiceSomething = MyClientProject.Something;

Now you can reference both types from within the same class / code file, referring to the service proxy class as ServiceSomething.

Edit: I actually recommend that you do not share your entities with the web service proxy. It makes versioning much more difficult. Just create a static SomethingMapping class that maps the instances back and forth and then never use the web service proxy class outside the class that uses the proxy.

Answer 3

Will this service only ever be called by .NET WCF Clients? If so, then when you create the service reference, you can tell WCF to share the existing type and not create a proxy version of the returned type.

This will only work with a WCF client, of course. Any other type of client will need to use a proxy class, which is the situation you appear to be in.

See Basics: How Web Services Work for an explanation. I originally wrote it about ASMX web services, but it applies to web services in general.

Answer 4

I'm going to suggest an alternative to doing what you're trying to do:

Rather than reworking your code so that you pass you MyProject.Something.Foo class through the web service, I suggest NOT doing so. Here's why:

By using your MyProject.Something.Foo class in the service contract, you are tightly coupling the class to your web service, and hence also coupling your web service's clients, which will need to generate their own client-side proxies (or equivalent). This coupling makes it difficult for you to change the implementation of the logic hidden behind your service contract in the future, because if you make a change which involves changing the class's public interface, you'll have to re-generate your proxies and change the contract published by your web service. And so will all of your clients.

Instead, I suggest that you generate the proxies with svcutil; keep your MyProject.Something.Foo class (which is your Business Logic layer) seperate; and write a bit of code to map between them. You are then much more likely to be able to absorb changes to your business logic class without having to break and re-generate your service contract.

What I'm (not very eloquently, having read this back) trying to get at is the SOA design principle known as "Services share schema and contract, not class" - give this a google and see what you think.

Hope this is helpful!