In this article the actual MVC like design will start to show up. The previous article, , didn’t really have anthing to do with MVC, so let’s begin!
Almost all design patterns will make re-use of code easier, but to accomplish this it is important to setup the Visual Studio Solution in such a way to support this. In the setup I will show here I will make way for re-use and the implementation of the MVC design.
I decided to start the process of creating a web service using an MVC like design pattern by specifying the interface towards the consumers. The interface has to be “nice”, and by that I mean that the parameters and return values should be easy to understand and use.
I will show how to define an XML schema using a third party tool, Liquid XML Studio 2008. These schemas will be used when generating C# classes/types to be used as parameters and return values when defining the web service interface. A result of this is that the web service will look like it uses objects as parameters, but this is only a way to represent the XML documents that may be used as parameters.
The other day I tried to compose an article about how to design an ASP.NET Web Service using an MVC like design pattern. I ended up with a huge article and decided to rewrite it and split it into a couple of smaller articles. I will try to write these articles as independent of each other as possible.
The idea to this subject came up when attending a course, held by Gabriel Svennerberg (http://www.svennerberg.com), dealing with Javascript, JSON and Javascript libraries such as JQuery and DOMAssistant. I wanted to try out the Ajax support in JQuery consuming web methods exposed by a regular SOAP web service as well as a WCF service. The business logic for these two interfaces were to be the same and their methods should have the same set of parameters, in and out. Therefore I wanted to create a couple of controllers and models to be used from the exposed methods. The methods themselves are the views in this MVC like architecture.
In this article I will explain how to implement a custom SOAP extension to be able log all incoming and outgoing SOAP messages passing through a .NET web service.
Sometimes the IIS log file is not enough when debugging or looking for errors in a web service. Let’s say that the web service works like a charm in the development environment, but then when a third party user starts invoking methods in the production environment it stops doing what it was built for. Then you have a need for this little extension, letting you log and analyze all incoming messages as well as the outgoing.