MVC onion architecture .

Primarily over the years I have worked mainly with ASP.NET web forms. Personally I have not had any issues with using web forms when working in small teams. I think when moving to larger development teams MVC seems to be the best platform to build on.

MVC(which stands for Model-View-Controller) lends itself to an Agile development methodology where TDD and BDD (Test-Driven and Behavior-Driven Development) are important components. Writing applications that are testable requires that you separate business logic from presentation logic so that they can be independently tested. This is a concept known as separation of concerns (SoC), which, in addition to testability, provides other benefits, such as greater application longevity and maintainability. The life of an application is extended because loose coupling makes it easer to upgrade or replace components without affecting other parts of the system.

This is where the “Onion Architecture” comes in. The term was first coined by Jeffery Palermo back in 2008 in a series of blog posts. It is intended to provide some insurance against the evolution of technology that can make products obsolete not long after they are developed (the technical term is “deprecated”). A classic example is Microsoft’s data access stack, which tends to change every few years (remember the demise of LINQ to SQL?). What Jeffery proposed (although he’s not the first) is for the application to reference interfaces so that the concrete implementation can be supplied at runtime. If, for example, the data access layer is represented by a number of repository interfaces, you can swap out LINQ to SQL with Entity Framework or NHibernate (or your favorite ORM) without breaking other parts of the application. This same approach is used to decouple things like configuration and logging so they become replaceable components.

In this depiction, the “core” of the onion is the object model, which represents your domain. This layer would contain your POCO entities. Surrounding your domain entities are repository interfaces, which are in turn surrounded by service interfaces. Representing your repositories and services as interfaces decouples consumers from concrete implementations, enabling you to swap one out for another without affecting consumers, such as client UI’s or tests. The data access layer is represented in the outer layer as a set of repository classes which implement the repository interfaces. Similarly the logging component implements a logging interface in the service interfaces layer.

Here is the project structure for a Visual Studio solution I created to demonstrate the Onion Architecture. I inserted solution folders and aligned project and folder names for ease of use. Infrastructure.Data uses dependency injection using castle Windsor through a property to implement repositories in Domain.Interfaces. The Web.Ui project accesses the services through a property in the controller class which implement the service Interface in Services.Interfaces. The actual service class in the Services.Service project also uses a property for injecting the repository to retrieve the data via your chosen method. E.g. entity framework and SQL or MongoDB). This solution structure can been seen clearly below in a screen shot of solution explorer. I have also taken a screen shot of the code map facility in visual studio 2013. This is a great tool for visualizing a call stack. I have highlighted how the web project implements the user service through Service.Interfaces decoupling the service layer from the web layer.

You may be asking, “How are concrete implementations of repositories and services created?” If components in the outer layer were to create instances directly, they would be tightly coupled to those implementations, defeating the whole purpose of the Onion Architecture and jeopardizing the application’s long-term viability. The answer is Dependency Injection (also known as Inversion of Control, or IoC). Components on the outer rim of the diagram have constructors that accept service or repository interfaces, and it’s the job of the DI framework to serve up a concrete instance, based on some initial configuration or setup. This wiring is done on application start up using Castle Windsor as shown below:

    
            
using Castle.MicroKernel.Registration;
using Castle.MicroKernel.SubSystems.Configuration;
using Castle.Windsor;
using Domain.Interfaces;
using Infrastructure.Data;
using Services;
using Services.Interfaces;
namespace Web.Installers
{
    public class AppInstaller : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            container.Register(Component.For<IDummyUserService>().ImplementedBy<UserService>().LifestyleTransient());
            container.Register(Component.For<IDummyUserRepository>().ImplementedBy<DummyUserRepository>().LifestyleTransient());
            container.Register(Component.For<IGalleryService>().ImplementedBy<GalleryService>().LifestyleTransient());
            container.Register(Component.For<IGalleryRepository>().ImplementedBy<GalleryRepository>().LifestyleTransient());
        }
    }
}

Jeffrey summarizes the key tenets of the Onion Architecture as follows:

The application is built around an independent object model.
Inner layers define interfaces; outer layers implement interfaces.
Direction of coupling is toward the center.
All application core code can be compiled and run separate from infrastructure.

MVC onion architecture .

Enjoy