EDABlog

... not hand craft wsdl

 

Custom messages reduce churn and change in the contract

 

Lets say you have this datacontract

 

[DataContract]

public class WorkEntry

{

[DataMember]

public DateTime StartTime;

[DataMember]

public TimeSpan Duration;

[DataMember]

public string User;

[DataMember]

public string CostCentre;

[DataMember]

string Comments;

}

 

What can go wrong here ? Using public fields is good , its tight and if you need to do custom things you can refactor it easily.  I think there is nothing really wrong here however if this is a business object also i would be concerned.

 The big gotcha maybe DateTime  , lets say you have some other systems in your company that use Java . Now Java systems use a nullable DateTime and can send null ( and DateTime.Min can become null if emit default values is false) causing all sorts of issues . Management decides YOU must change however you have used this as a business object through your app . You can change the DateTime to DateTime? However there are a large amount of implication to your application in now having to deal with possible null values - including the SQL server and DB and hence what is a trivial change requires pretty a lot of work and risk and hence testing ( note TDD or unit testing here do not help and make it worse as the unit tests also have to change) .

The problem here comes from using your DTO ( data transfer object eg message /DataContract) as your business object. I think this should be avoided in all cases where the service is non trivial. In Trivial services its easy enough to write a new service or make the changes and hence using the business object as the message is ok.

Avoid .NET specifics especially

• non int integer types
• char 
• generics ( not that it works)
  
• serializing interfaces
• inheritance

Ultimately messages are serialized as XML and forcing a object model onto it will always result in difficulties and leaky abstractions for the domain.  The solution is simple DONT let WCF and your communications contaminate your object models use the DTO(Data Transfer) pattern.

see DTO pattern.