Why split layers? What are the benefits of a multi-layered architecture?

Asked

Viewed 5,927 times

27

There are n types of architectures that use layer separation, an example: Model-view-controller (MVC).

  • How creating multiple layers can help my application?
  • What are the advantages of doing this? And the disadvantages?
  • The more layers "the better"?
  • What situations that the use of this type of architecture is not recommended?

Note: The question isn’t about MVC, it’s about this kind of multilayered architecture.

  • MVC nay is a kind of architecture, is a Pattern design that idepende of the layers in its architecture.

4 answers

23


Not to confuse multi-layer with multi-tier. Of course architectures multi-tier probably only work if the application is multi-layer.

The more layers "the better"?

I’ll start with the simplest. The fewer layers, the better. It is obvious that adding layers makes the software more complex. Of course this does not mean that only one layer is ideal. You have to analyze the specific problem and which will bring more advantages.

Certain complexities exist to solve certain problems, to meet certain requirements. If not for this a layer is better because it is simpler. Today almost everything has more layers because there are requirements that require this but no one should make the software more complex just because it was written in a book that should do this.

There are cases where one layer is too good. There is no reason to add layers in simple systems with few changes developed by a programmer where you know the exact environment where it will work. Trying to add layers in this case is going against the YAGNI and add unnecessary development cost.

Adding another layer is useful because it allows you to separate business rules from the user interface. At least this is what happens in most cases. This is a huge gain in terms of organization but it will make you have to deal with the same entity in two different locations. It has techniques to minimize some duplicities but complicates development.

Then you need to analyze if the gain pays. Only experience gives subsidies for this. And even then the chances of an evaluation being wrong is great. Nor is it easy to measure. This is why it is common for people to opt for a definite pattern and go with it in any situation. It seems that it is better to make a mistake because you did what everyone else does than to do what is possibly best for the specific case. But I do not agree with this.

3 layers

The most common is to have 3 layers (It is scary that this only exists in Portuguese). To tell the truth I don’t know anything useful with more than this. In 3 layers business rules are best organized by separating the data model from the way they should be handled by the application when interacting with other parties, especially with the user interface.

The use of 3 layers is triggered the most used by decoupling all the necessary parts and give more flexibility in how to assemble the application, without exaggeration. You have the layer of presentation, of applying and of business. There are cases that the latter delegates persistence and other operations to a fourth layer. It may be exaggeration. Although used a framework that abstraction all work can be advantageous. But then it seems that you only have 3 layers again.

What are the advantages of doing this? And the disadvantages?

  • The biggest advantage is being able to change certain components, make parts of the independent application. Being able to make changes in one part without affecting the others.

  • It is also useful for multiple developers (not necessarily programmers) can work in the same application each taking care of the part where he is an expert.

  • Gets more easy to test.

Downside

If the development is done by a person or the developers have their tasks defined by other criteria and the application does not need today and will not need tomorrow a change of its components, using layers is mental masturbation. IS increased complexity for nothing.

When to use

One of the best known Erps in the market, which I worked on, achieved its success with just one layer. Of course, at some point he had to add layers, but he can do this almost transparently for the application, in most cases. And of course we learned that marketing is more important than engineering :)

Not use

In internal systems where the team is very small, the database is known, if you know where it will run, what the exact needs of those users, layers tend to be overzealous. Don’t create complexity where you don’t need it.

Web

Today has a factor that must be considered. The Web! Systems need to work on a technology that is multi-tier and so it needs to be multi-layer. And in cases where the solution also runs in desktop there is one more reason for flexibility. That is, the market now has a requirement that has made the multi-layer almost an obligation.

Scalability

Architectures multi-tier usually allow more scalability. And this happened to be a new requirement in some cases, but not in the majority. And as said before, multi-tier demands multi-layer.

User interface

The most common architecture standards for user interface (seems to be the focus of the question) in 3 layers are: MVC, MVP, MVVM. They have probably become known to be tied to the successful technologies. See more in What is MVP and MVVM?.

  • I think more than 3-tiers is when one layer breaks into several. In Java it is easily seen, for example, what I believe to be the View can be subdivided into Applets being grouped as Client Tier and Servlets being classified as Presentation Tier. Of course a Java programmer can confirm better than.

  • It may be, as I don’t know these technologies, I can’t say.

  • 1

    "The fewer layers, the better." Exactly that. A lot of Java people take the Core JEE Patterns book and apply it to the letter. Then no one can maintain the system, since only to recover an entity from the Controller the code goes through 500 layers. The systems get full methods that only have one call to another method and over time various classes cease to be used, but no one has the courage to exclude because there is no traceability to give assurance that they are not used somewhere obscure between all layers.

  • 1

    @utluiz This is the biggest criticism I have of "Java". Its users have learned to do complex things by default. And general education nowadays is very much on top of this. It has a lot of material (books, blogs, etc.) to solve really complex problems but people don’t understand that the older materials that propose simpler solutions are not obsolete. They just don’t answer to everything.

  • There must be people who think that to be a good architect, accurate create a new layer, hehe. Comic: http://geek-and-poke.com/geekandpoke/2013/7/13/foodprints

10

N Layers are styles of architecture, MVC is a Pattern design. Many people confuse this. You can apply for example a 3-layer architecture together with MVC, in this case it would be the view layer.

MVC is quite common nowadays, but it is a very old term already. Spring MVC, Struts and several others use this Pattern.

That said, the N-layer architectures separate the responsibilities of your application. For example, the 3-layer:

  1. Interface
  2. Logic
  3. Access to the bank

The first is the interface (HTML, Swing, JSP, JSF, etc), where the user will interact.

The second part of business (business) where you find most or all the logic of your app, as for example, validation, sending email, calculations and accounts and etc.

The third and last would be all access to the base.

See, if you need to maintain access to data, you will go directly to your related layer and change only that part of the code. That’s great on big projects

Okay... but what for all this ?

  • You clearly have a separation, which can be even of projects. What is great when worked on multiple people as it facilitates maintenance and deploy.
  • Decoupling: Each layer communicates with each other through Interfaces.

The more layers, it doesn’t mean any better. Please read on Cohesion and Coupling and also on Granulity that you will understand better the "why".

Note: Do not apply hundreds of Patterns design and layers etc. stick to the simple, the simpler the better. Program thinking about maintenance, and others who may come to program on top of your code.

Hugs

2

Why use an MVC?

Because it is a true design standard (Pattern design) and makes it easy to maintain your application, with modular packages of rapid development. Crafting tasks divided between models, views and controllers makes your application light and independent. New features are easily added and you can put a new face on the old features in the blink of an eye. The modular and separate design also allows developers and designers to work simultaneously, including the ability to build a rapid prototype. Separation also allows developers to change one part of the application without affecting others.

http://www.forumweb.com.br/faq/668/cakephp/quais-os-beneficios-de-se-usar-mvc

I honestly have never seen any kind of development that does not accept MVC architecture. I consider it a great evolution in the area of programming. Here at my company we used this architecture long before it was published as it is today.

  • 1

    So what would be a fake design pattern? When you create layers, put a new functionality should be done in several places, is this more easy? Anyway, the question isn’t about this.

  • But just by the organization is already a very good bigown architecture and I bet you intimately agree with me.

  • Now I think the answer besides not answering the question is based on opinion. It’s bad enough to get a full answer, but you could at least get a good answer.

  • So bigown respond to us with a better answer, we want to understand...

  • Rogers, I used MVC as an example, did not ask the specific question about MVC, I will edit my question.

  • Is answered.

  • Really bigown, very good the answer is no wonder your reputation is high. Will I have to vote to do what? P

  • 1

    careful, MVC is not exactly a Pattern design, but an Architecture Pattern.

Show 3 more comments

0

MVC is simply separating the 3 layers of Model, View and Controller. It’s a simple paradigm, an idea that you should take into account whenever you develop classes. Always looking to not mix the code of different categories into a single class.

For example, a grid view table should show the content when loaded, however there should be no encoding where it fetches the data. Just like a function that sums up a column should occur in the controller.

Separation of responsibilities allows flexibility during coding, it is important to separate the view from the model, and then add other subclasses.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.