paulpierce.co.uk

WCF offers several different approaches for writing Web Services; Contract first, Code first, with slight variations on either approach.

I personally prefer the Code first approach and find it much easier to think of messages in terms of objects. With the Code First approach in WCF, you define a contract which will later be used to generate your WSDL. WCF provides Data Contracts as the preferred approach to abstracting out your message.

To use Data Contracts you mark your class with the DataContract attribute and the properties you wish to expose for serialisation with the DataMember attribute, the object would then serialised using the DataContractSerializer; a limitation with this approach is that you don’t have full control over serialisation, so it would be difficult to work with classes that may have been generated using xsd.exe for example.

WCF offers another Code First solution that gives you full control over serialisation; you can mark your classes with the Serializable attribute and the Service Contract Interface with XmlSerializerFormat attribute to leverage the XmlSerializer.

The XmlSerializerFormat approach seemed like an ideal solution to a recent project, giving me full control over the serialization of the soap body. I next needed to do a similar thing to the soap header. WCF uses Message Contracts to give you control over the soap message, you basically decorate the class that represents your message with the MessageContract attribute then properties in that class with MessageHeader and MessageBody attributes, represent the SOAP header and SOAP body respectively.

The abstraction the SOAP envelope using the Message Contract is not compatible with the XmlSerializerFormat approach, you can only use it with DataContract approach and there doesn’t appear to be a similar abstraction to use with the XmlSerializerFormat approach. This has left me a bit puzzled as to the best way to harness the XmlSerializer for SOAP headers. I’m sure the answer must be to dip into the WCF pipeline at another point to process the header, but nowhere feel’s natural to do so.

Any thoughts or ideas on this would be welcome.

I haven’t written a blog post for ages, so as a (few weeks after) New Year’s resolution I am going to try to write a bit more regularly.

I am studying for the MCPD Web Developer exam, so hopefully I will get a bit of inspiration from some of the things I learn.

I have also been looking at WCF in work, so will probably have a few posts related to that, as I try to get to grips with what seems a very powerful way to develop web services.

There is a whole host of other new thing to learn, such as LINQ, WWF and WPF. Where am I going to find the time??

I have read about the benefits of aspect orientated programming (AOP) and decided to investigate the possibility of using an open source AOP Framework to standardise exception handling in our application.

Click here for a list of Open Source Aspect Orientated Frameworks

From what I had read I had great hopes for AOP: I was expecting to be able to add exception handling and logging to some classes by writing an exception handling class using the AOP framework and then using a configuration file, configure which classes magically had exception handling applied.

Unfortunately there is no such thing as magic (sorry kids), there needs to be a way of weaving the code written for exception handling (Advice) into the methods specified by the configuration file.

The AOP frameworks seem to take two different approaches to weaving, Compile time weaving and Run time weaving; each of these solutions have their own compromises.

I initially discounted using a Compile time weaving framework such as AspectDNG, because of the impact on our build process.

I first looked into Runtime weaving implementation AspectSharp but after discovering a bug running their example I found a message on the forum saying the AspectSharp project had stalled. I next looked at the SpringFramework which at first seemed promising, I was disappointed to find out that in order to use runtime weaving you are faced with a few rather large compromises: Firstly the classes in which you want to apply the Advice to have to implement an interface, which isn’t so bad I suppose. Secondly however there is a bigger compromise, every call you make to your classes must be replaced with a call to a proxy.

so

command.Execute();

would be replaced with,

ICommand command = (ICommand) ctx[”myServiceObject”];
command.Execute();

Is this intrusive use of a proxy just a bit too much of a compromise to have your domain logic free from distractions like tracing and exception handling? I suppose the answer is “it depends”. For my situation this was too much of a risk, I didn’t have time to investigate any performance penalties, but this surely must be an issue too.

The future of AOP must be with compile time weaving; if this could be integrated smoothly with Visual Studio and the build process then this surely would be an attractive option.

Encapsulate Collection is a refactoring from Martin Fowler’s book Refactoring: Improving the Design of Existing Code, the refactoring is applied when you have a class with a public property of a collection type, the intent is to stop the collections internal data structures from being exposed.

I was thinking about how to apply this refactoring using .NET 2.0 and generics and decided on the implementation below;

public class Order
{
private List<IOrderLine> _orderLines;

public ReadOnlyCollectionList<IOrderLine> OrderLines
{
get { return _orderLines.AsReadOnly(); }
}

public Order()
{
_orderLines = new List<IOrderLine>();
}

public void AddOrderLine(IOrderLine orderLine)
{
_ orderLines.Add(orderLine);
}

}

The generic ReadOnlyCollection Class provides a base class for a generic readonly collection, using this class as opposed to the generic IList, has the advantage that someone implementing the class can see at design time that the class is readonly; however the generic IList may be a better alternative as more of collections internal data structure is hidden: any thoughs on this would be much appreciated.

I am have just started a new .Net 2.0 project in my spare time, I will be developing an estimating app. We are soon to be moving over to .Net 2.0 in work, so hopefully this project will give me a chance to get up to speed.

I also want to try out some new things, like Object Relational Mapping, which really seems like a big step forward; this was one of the features that really impressed me about Rails. Rails enforced the Active Record Pattern; I assume that .Net implementations will be a little more flexible.

One of the things that concerned me initially about object relational mapping was the potential performance hit over the traditional approach of using stored procedures, in the book I am currently reading Applying Domain-Driven Design and Patterns: With Examples in C# and .NET the author suggests that ORM could be used for the majority of the code, with performance critical parts being written with stored procedures; this really seems like a good idea to me, I can imagine the time that could be saved on the majority of projects using this approach.

When unit testing you should try to test the class of interest in isolation, this means removing any dependencies with other components; for example I needed to test in isolation a class that is instanciated by passing to it an object that implements IDataReader.

public DictionaryItem(IDataReader)

By creating a mock object for IDataReader, the class can be tested in isolation of the Data Access Layer (DAL).

You could either create the necessary mock object, by building your own class implementing IDataReader or use a mock object framework to help you.
For some time now NMock has been regarded as a powerful framework for generating mock objects, however the original NMock had a few limitations, one of which seemed to prevent nmock from being used to test a class that exposed an indexer. Fortunately NMock2 the new version of nmock, solves this problem. NMock2 is a total re-write micking jMock were “expectations are expressed in a more conversational style”; this makes NMock to easier to work with than its predecessor.

The following code creates the dataReaderMock mock object, which can then be passed to my DictionaryItem class in my unit test;

Mockery mocks = new Mockery();

IDataReader dataReaderMock = (IDataReader)mocks.NewMock(typeof(IDataReader));

Expect.AtLeastOnce.On(dataReaderMock).Method(”Read”).Will(Return.Value(true));
Expect.Once.On(dataReaderMock).Method(”Read”).Will(Return.Value(false));
Expect.Once.On(dataReaderMock).Method(”NextResult”).Will(Return.Value(false));
Expect.Once.On(dataReaderMock).GetProperty(”IsClosed”).Will(Return.Value(false));
Expect.Once.On(dataReaderMock).Method(”Close”);

Expect.Once.On(dataReaderMock).Get[”COL_1″].Will(Return.Value(4));
Expect.Once.On(dataReaderMock).Get[”COL_2″].Will(Return.Value(”col1ValueExpectedByUnitTest”));
Expect.Once.On(dataReaderMock).Get[”COL_3″].Will(Return.Value(”col2ValueExpectedByUnitTest”));
return dataReaderMock;

As you can see the expectations on a Mock2 object are easy to read; at least one expectation is made for each propety or method you expect to be called. The expectations reflect how the constructor of DictionaryItem will use the IDataReader; in my case the mock object reflects an DataReader with only one DataRow. The first part of the expectation defines how many times you expect the method to be called “Expect.AtLeastOnce.On”, the second part defines the name of the method, property or indexer expected to be called “Method(”Read”)” and the last part defines what value should be returned “Will(Return.Value(true))”.
If you use the mock object an nunit test if any of the expectations have not been met, the test will fail.

Download NMock2, NMock2 Tutorial