Most of the people use n-layered architectures in their application developement. There are lots of advantage for n-layered architecture but I want to talk about disadvantages. actually it's not a good idea to design a somplex architecture for every problem , you don't need to apply n-layered architecure 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 picture below:
When you make a request from your browser your request goes throw several layers and assemblies to persist your request in data base 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 user in "ContactUs" of n-layered architecture web site (the same example I showed in StackOverflow).
This is my action to create the Contact:
- public ActionResult Create(ContactViewModel contactViewModel)
- var request = new CreateContactRequest(contactViewModel);
- 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();
- response.Success = true;
- response.MessageType = MessageType.Success;
- response.Message = ServiceMessages.GeneralServiceSuccessMessageOnCreation;
- catch (Exception exception)
- response.Success = false;
- response.MessageType = MessageType.UnSuccess;
- response.Message = ServiceMessages.GeneralServiceErrorMessageOnCreation;
- return response;
And finally in repository layer, I have this generic Add method:
- public void Add(T 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:
- public ActionResult Create(Contact 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 try to use something like that as it's easy to develop and defiantly high performance.
Optimizing n-layered architectures is not 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 specially 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:
- This architecture leads to reduction of network traffic, faster network communications, greater reliability and greater overall performance.
- As layers usually live in separate assemblies so This results in high communications overhead.
- More layer cause more network and network bandwidth, process involved.