WCF DataContract class with methods

Question

This is more of a philosophical/best-practice sort of question rather than a technical problem.

Are there any strong arguments against writing a DataContract class with methods that are to be used server-side only? Or what about additional properties that are not decorated with the DataMember attribute?

For example:

[DataContract]
public class LogEntry
{
  [DataMember]
  public string Message { get; set; }
  [DataMember]
  public string Severity { get; set; }

  public string SomeOtherProperty { get; set; }

  ...

  public void WriteToDatabase()
  {
    ...
  }
}

Not doing it seems like an awful lot of extra work that I would prefer to avoid, although using extension methods could make it easier. But, as a good developer, I am wondering if it is bad practice to do so.

What do you think?

Cheers, Jean-Michel

Answer 1

You certainly can add anything you want to the type because as far as WCF is concerned, only memebers that have explicitly opted-in as DataMembers are part of the contract and will be serialized as such.

I think that it is cleaner to not put extraneous members into a contract as that can be confusing when you are using the type.

Answer 2

Actually, it really depends on the context

by context I mean: First project management context : money budget/time/developpers level/expected life time of your project Then WCF context : is it a webservice (wsdl) or a namedpipe transfer

If you are short on everything and you do not expect anybody than the clients you are developping to connect to the web service and you feel confortable with this approach do it.

In all the other case, I would suggest to cleanly split the contract code from implementation details.

Note that in a WCF namedpipe context, you could be interested in implementing only once this contract in an assembly shared by both the clients and the server. In this case you risk to expose to clients signatures of the server.