Take the 2-minute tour ×

I am working on a server-client app in c# and need to send an object from the client to the server via WCF. For simplicity I will call it WorkingClass as it is what does the work.

    public class WorkingClass 
        public WorkingClass (FileInfo uncompressedFile, FileInfo compressedFile)
            UncompressedFile = uncompressedFile;
            CompressedFile = compressedFile;

        public FileInfo UncompressedFile { get; private set; }
        public FileInfo CompressedFile { get; private set; }

        public void ZipFile()
            //zip file

Now I need to send it to the server via WCF. I don't need the whole WorkingClass FileInfo properties serialized and sent, so I have a simple class which I will call MessageClass that has simple strings.

public class MessageClass
        public MessageClass(string uncompressedFileName, string compressedFileName)
            UncompressedFileName = uncompressedFileName;
            CompressedFileName = compressedFileName;

        public string UncompressedFileName { get; private set; }
        public string CompressedFileName { get; private set; }

I can add a ToMessage() instance method and a FromMessage static method to the WorkingClass. Or instead of the static FromMessage method, I could add a constructor to the WorkingClass that accepts a MessageClass as a parameter. To me these options seem to tie both classes tightly together and the WorkingClass should only have to worry about zipping a file, not converting itself for communication via WCF. Do I maybe create a converter class?

The Server will then need to convert from the message to its own working class.

Am I on the right path to handle this sort of thing? Is there a best practice or design pattern I can follow?

share|improve this question
If I'm not mistaken WCF uses Data Contracts for the serialization? I figure it won't work without applying those attributes. –  Steven Jeuris Oct 20 '11 at 12:30
Create a DataContract of the info you want to send to the server, and then create a method in your OperationContract that takes an instance of whatever class is your DataContract. Take a closer look at how WCF works. –  Steve Evers Oct 20 '11 at 12:31
@SnOrfus: This could probably be an answer. –  Steven Jeuris Oct 20 '11 at 12:34
Yeah, the MessageClass is my DataContract (not called that of course). I simplified it for the question. The WCF side is not the problem. The problem is I don't want/need to send the whole WorkingClass to the server. It just needs both of the WorkingClass.FileInfo.FullName properties so it can do it own work on that data. My question in this case is really about what is the best practice for transforming a class into a data contract. –  John Petrak Oct 21 '11 at 1:07

2 Answers 2

up vote 3 down vote accepted

All of the methods you've mentioned are perfectly valid.

The way I look at it though:

  • MessageClass is for communication via WCF only. What I mean by that is you have your server application which consists of the server component itself and a way for your client to communicate with it which in this case is WCF
  • WorkingClass is part of the server component itself, it should not worry about how the client communicates with the server

I'd put the code of converting between the two in the WCF using a helper/converter class.

share|improve this answer
Using a converter class is the most flexible approach. You could optionally use different converters for different scenarios. Using a method wouldn't give this flexibility. Also, the converter class handles the coupling, so there is no dependency from the WorkingClass to anything communication related. –  Steven Jeuris Oct 20 '11 at 12:24
Yeah, I am thinking that a converter class is the better way to go. Being flexible makes sense. It will allow me to create another converter if needed without filling up my working class with converter methods. –  John Petrak Oct 21 '11 at 1:13

It looks like you have some code duplication going on that keeps you from resolving your issue. The working class should contain a method that accepts a message (if neccesary store it in a local field) Then the message class is the only type that needs to be serializble(add datacontract) and even might be in a shared library on the client and server.

By doing so you can expose the zipfile(MessageClass msg) as an operation to WCF (using an interface off course) and it pretty much will take care of the rest.

share|improve this answer

Your Answer


