C#: Partial Classes & Web Services: Seperating form and functionality

Question

Hi all,

I am dabbling in the world of web services and I've been making a simple web service which mimics mathematical operations. Firstly it was simple, passing in two integers and then a binary operator would be applied to these (plus, minus etc) depending on the method called.

Then I decided to make things a little more complex and started passing objects around, but then I discovered that a web service only exposes the data side of the class and not the functional side.

I was told that a good way to deal with this is to make the class on the service side a partial class (this side of the class encapsulating form) and on the client side have another partial class (where this side of the class encapsulates functionality). This seems like an elegant way of doing things..

So, I have set up two classes as described above, but it doesn't seem to be working as I was told.

Is what I am attempting possible? If so, where am I going wrong?

Thanks,

Nick :-)

Answer 1

Not with partial classes. A partial class is a syntax construct that gives you the ability to have different parts of the class in different source files. However, all parts of the partial class are ultimately compiled into the same binary.

You could use extension methods to add functionality to your class that represents the data contract.

You could also try implementing the class in a shared assembly and use the svcutil.exe /reference to get it imported in the client proxy instead of having a brand new declaration in the web service namespace.

Answer 2

As Franci said, it simply allows you to put separate parts of the same class into different files.

How you should structure things instead really depends on what you are doing. If I were you I would likely have a rather plain data carrying class and a consumer which could be used to process that data.

The use of a shared assembly is also a good idea. However, if you really wanted to be able to send the code from the server to the client CSharpCodeProvider would work.

Answer 3

Partial classes are really a tool to separate auto-generated code from developer code.

A good example is the windows forms designer in VS, or the new DBML Linq DataContext generated code.

There's also an argument for using them with VSS style source control providers where only one user can edit a file at any one time.

It's not a good idea to use them for logical separation of functionality - the division only exists pre-compilation. As soon as you compile you get just the one class, but not one that it's easy to debug or track operations inside.

What you've described sounds like a really good situation for using WCF contracts. In that case both client and server would share an Interface (or Interfaces).

Your complex code would go there and could be unit tested separately - i.e. outside of your connected application. Then when bugs are found you can eliminate code issues quickly and move to investigating connection related ones instead.

Answer 4

(This thread's probably dead but...) I was thinking of doing something similar, but with the functionality on the (in my case) Windows Service.

Both the client program and the Windows service need access to the data, but only the service needs to actually do anything with the data; they are both including in a dll that holds a partial class containing contracted data members, however I get an error saying this partial class conflicts with the partial class on my service even though they are both in the same namespace and at the moment, the server's partial class is empty.