Blog

Most of the people use n-layered architectures in their application development. There are lots of advantage for n-layered architecture but I want to talk about the disadvantages. actually, it's not a good idea to design a complex architecture for every problem, you don't need to apply n-layered architecture in every case because it's mostly about making complex things simple whilst a complex architecture can make a system more and more hard to understand rather than making performance problems. Based on this presentation, making software via n-layered application could be cost-effective and dangerous for performance. Suppose an architecture like the picture below:

 

When you make a request from your browser your request goes throw several layers and assemblies to persist your request in database and then comes back the same way to make a change (you can simply assume the scenario like the picture!). Let's take an example about that, imagine that I'm gonna to persist the sent message(Contact) by the user in "ContactUs" of the n-layered architecture website (the same example I showed in StackOverflow).

This is my action to create the Contact:

 

[HttpPost]
public ActionResult Create(ContactViewModel contactViewModel)
{
    var request = new CreateContactRequest(contactViewModel);
    _contactService.CreateContact(request);
    return View();
}

 

and about the service implementation, I've done like this:

 

public CreateContactResponse CreateContact(CreateContactRequest request)
{
    var response = new CreateContactResponse();
    var contact = request.ContactViewModel.ConvertToContactModel();
    try
    {
        _contactRepository.Add(contact);
        _unitOfWork.Commit();
        response.Success = true;
        response.MessageType = MessageType.Success;
        response.Message = ServiceMessages.GeneralServiceSuccessMessageOnCreation;
        _logger.Log(response.Message);
    }
    catch (Exception exception)
    {
        response.Success = false;
        response.MessageType = MessageType.UnSuccess;
        response.Message = ServiceMessages.GeneralServiceErrorMessageOnCreation;
        _logger.Error(exception.Message);
    }
    return response;
}

  

And  finally in the repository layer, I have this generic Add method:

 

public void Add(T entity)
{
    SessionFactory.GetCurrentSession().Save(entity);
}

 

As you can see there are lots scenario in this example such as converting ViewModel to Model, using request and response pattern in Service, injecting the interfaces,  adding to the repository, committing by UnitOfWork and blah blah. But you I can also do all of above with just a simple action method:

 

[HttpPost]
public ActionResult Create(Contact contact)
{
    SessionFactory.GetCurrentSession().Save(contact);
    return View();
}

 

You know the above implementation on an action is not the best solution when your application is complex and large scale, but if it is not trying to use something like that as it's easy to develop and defiantly high performance.

Optimizing n-layered architectures is not an easy task, But it is easy to change the content of any layer without making corresponding changes in other layers. It is more readable, maintainable, extensible, flexible, testable and is suitable for parallel development especially in team working but you know it has its own disadvantages.

If you have enough factors to break your application into layers, for example, if you want to let other applications to access to your application via a service, separate your concerns; so apply to layered architecture but keep in mind that:

 

1. This architecture leads to the reduction of network traffic, faster network communications, greater reliability, and greater overall performance.
2. As layers usually live in separate assemblies so This results in high communications overhead.
3. More layer cause more network and network bandwidth, the process involved.