LM Tech's blog

Software Architecture & Design Patterns

In the post Design a RESTful service with .NET framework 4.0 i've shown how to create a RESTful service using .Net Framework 4.0.

Let's see now how to consume the service through a .Net client application. We will use the WebClient class defined in the System.Net namespace for sending and receiving data to or from the RESTful service, and the DataContractJsonSerializer class to serialize and deserialize an instance of a type to or from a JSON document. More...

This post shows how to implement a RESTful service using .NET framework 4.0.

Using the REST terminology, we will call "resource" any object, identified in an unique way by an URI, on which to invoke one of the "request methods" ADD, PUT, DELETE, GET.

In our example the resource is represented by the "Contact" object defined as follow:

public class Contact
     public int ContactId { get; set; }
     public string fName { get; set; }
     public string lName { get; set; }
     public string eMail { get; set; }

Implement a RESTful service in .NET 4.0 is simple as to write a wcf service. Infact .Net 4.0 provides a very simple REST programming model thanks to the WebInvoke/WebGet attributes.
Is sufficient decorate the service operation with one of these attributes and it can be called by the WCF REST programming model.

The WebInvoke attribute exposes some properties through which you can specify the REST options:

Method: Gets and sets the protocol (for example HTTP) method the service operation responds to (ADD, PUT, DELETE, GET)

RequestFormat: determines the format of requests made to a service operation. The possible values are Xml and Json.

ResponseFormat: determines the format of responses sent from a service operation. The possible values are Xml and Json.

UriTemplate: determines which requests get dispatched to which service operations.

You can also use the WebInvoke attribute insted of the WebGet attribute specifying Method = "GET".

Here an example of service contract:

public interface IContacts
    [WebInvoke(Method = "ADD",
         ResponseFormat = WebMessageFormat.Json,
         RequestFormat = WebMessageFormat.Json, UriTemplate = "Add")]
    Contact Add(Contact contact);

    [WebInvoke(Method = "DELETE",
        ResponseFormat = WebMessageFormat.Json, UriTemplate = "Delete")]
    void Delete(string id);

    [WebInvoke(Method = "PUT",
        ResponseFormat = WebMessageFormat.Json)]
    void Update(Contact contact);

    [WebInvoke(Method = "GET",
        ResponseFormat = WebMessageFormat.Json)]
     List<Contact> GetAll();

    [WebInvoke(Method = "GET",
        ResponseFormat = WebMessageFormat.Json, UriTemplate = "GetContact/{id}")]
    Contact GetContact(string id);

In a typical scenario, the service contract IContacts could be implemented by the Contacts.svc service, hosted at the address http://myserver/contactservice/Contacts.svc.

In this scanario the service operations can be invoked in the following way:


One of the most relevant issue in software architecture is how to separate the implementation of cross-cutting concerns from the implementation of the core-concerns.
A cross-cutting concern is a concern that affects multiple components in a system, such as logging, security, and exception handling.
Microsoft's Unity Application Block (Unity for short), that is part of the Microsoft Enterprise Library 5.0, enable you to effectively capture calls to objects and add additional functionality to the target object. More...

The factory design pattern is a creational pattern that favor the abstraction of the objects creation's process.
The creation of an object can be a complex process where many properties must be setted and other nested objects must be created.
To reduce the code duplication and the coupling between classes, is better to put the creation code in a unique place (the factory), where you can access to get the instance of the objects.
A "factory" therefore, is an object for creating other objects. More...

Microsoft's Unity Application Block (Unity for short) is an Inversion of Control framework wich is part of the Microsoft Enterprise Library 5.0.

Unity is a general-purpose container for use in any type of Microsoft® .NET Framework-based application. It provides all of the features commonly found in dependency injection mechanisms, including methods to register type mappings and object instances, resolve objects, manage object lifetimes, and inject dependent objects into the parameters of constructors and methods and as the value of properties of objects it resolves. More...


The delegate is a reference type that can be used to encapsulate a method with a specific signature. Delegates are similar to function pointers in C++; however, delegates are type-safe and secure.

The delegate is declared using the keyword delegate: More...

A callback is a reference to a portion of executable code, that is passed as an argument to other code.
Using callback, for instance, a server program can notify to a caller when the requested operation ends. The callback paradigm can also be used instead of the Observer Design Pattern. In Microsoft .Net Framework, callbacks are implemented using delegates that provides type-safe function pointer.

A delegate is declared using the delegate key-word:

public delegate void OperationCallbackDelegate(int value);

Another way to implement the Inversion of Control (IoC) principle, in addition to the Dependency Injection, is the plug-in design pattern.

The pattern consists in to load an assembly that implements a common interface at runtime. In this way, a class that depends from an object in an other assemby is completely decoupled from it, or rather, it has no reference to dependent assembly. More...

Events are mechanisms that allow application-specific code to execute when an action occurs. In Microsoft .Net Framework events are implemented using delegate (the event handler).

A delegate is a reference type that can be used to encapsulate a method with a specific signature and lets you pass a function as a parameter in type-safe manner. More...

The Separated Interface pattern addresses the problem of separating the interface that describes the functionalities from its implementation. The pattern prescribes that you use different packages (assemblies in the .NET Framework) for the interface and any of its implementations. The packages that need to consume the functionalities know only the definition of the interface and are completely unaware of the implementation. More...