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.
MVC
The MVC (acronym for Model-View-Controller) design pattern is a fairly straight forward pattern. The primary goal when using MVC is to isolate the business logic from the user interface. Wikipedia presents the pattern in very nice way, so read about it on Wikipedia (Model-view-controller).
A great article about applying MVC to an ASP.NET Web application is Implementing the MVC Design Pattern in ASP.NET.
Don’t forget the ASP.NET MVC Framework on http://www.asp.net/mvc/! My good friend Gabriel Svennerberg (http://www.svennerberg.com) has a lot of experience using this and we are impressed by the work Scott Gu and his crew have performed when developing the ASP.NET MVC Framework.
The web service to be implemented
The goal for this series of articles is to implement a couple of web methods handling images. The web service will have two methods exposed to the consumers:
- SaveImages: A consumer will be able to save images to a data store.
- GetImages: A consumer will be able to get images matching the search criteria passed as a parameter.
The steps to accomplish this will be:
- Defining service interface types (using XML schema tools)
- Setup an ASP.NET Web Service Solution in an MVC like way
- Implementing the business logic
- Re-use of the logic, creating a WCF service
1. Defining service interface types (using XML schema tools)
This step is about using an XML schema tool to define a set of types to be used as parameters and return values when developing (web) services. The tool used to create the schemas is Liquid XML Studio 2008, found at http://www.liquid-technologies.com/Product_XmlStudio.aspx. This tool (free under the FREE Community Edition License) is the best XML schema tool I have ever used. The procedure of defining a schema is really really simple, and the possibility to generate example XML documents is great! Not to forget, it integrates with Visual Studio nicely.
The schema will then be used to generate C# classes using the xsd tool that comes with the Microsoft Windows SDK. This tool can be used to generate classes in a number of languages (C#, Visual Basic, JScript and Visual J#) from the XSD created using Liquid XML Studio. Read more about this tool on MSDN, http://msdn.microsoft.com/en-us/library/x6c1kb0s(VS.80).aspx.
2. Setup an ASP.NET Web Service Solution in an MVC like way
Here I will present a step by step procedure to setup a Visual Studio Solution in a way that will make it easy to implement the functionality in an MVC like way, as well as to make the code easy to re-use later on.
3. Implementing the business logic
This is the step where the actual stuff happens. The logic will be implemented, using the solution setup in step 2. I will also implement a test client for the exposed methods. This client may be extended in a possible step 4 to use the WCF service created in that step.
4. Re-use the logic, creating a WCF service
Maybe I will add this step describing how to re-use the logic already implemented. I’m not sure I will ever do this, but the plan is to show how easy it is to re-use the code (assemblies) created in step 3. This is done implementing a WCF service to be cosumed by the same test client implemented in step 3.
Continue the reading
Step 1:
Step 2:
Step 3: [To be published]
Step 4: [To be published]