É comum as pessoas dizerem que se utilizarem um design pattern a aplicação estará separada em camadas, como é normal ouvir quando as pessoas falam de MVC. Mas será que design pattern não está sendo confundido com arquitetura de sistemas?
Um sistema multicamadas é quando as partes de um sistema estão separadas fisicamente. Por exemplo: em um sistema de 3 camadas a separação seria entre a regra de negócio em um servidor, o banco de dados em outro e a apresentação em outro. Já o MVC é um design pattern, ou padrão de projeto, que é utilizado para organizar a aplicação em camadas lógicas para facilitar a manutenção de um sistema, ou seja, o sistema é dividido em diversos pacotes dentro de uma mesma solução para que o desenvolvimento do mesmo seja melhor interpretado.
Imagem via Shutterstock
Muitas vezes esses assuntos se confundem porque para se ter um sistema multicamadas, é quase que obrigatório utilizar um design pattern para fazer a separação lógica do código e depois a separação física, mas para utilizar um design pattern não é necessário ter uma arquitetura multicamadas. O MVC, design pattern criado na década de 70, ainda é um dos mais utilizados nas aplicações atualmente devido a sua flexibilidade, pois pode integrar-se com as diversas linguagens de programação: ASP.Net, Java, C#, Python, Ruby on Rails, entre outras.
As vantagens de utilizar uma arquitetura multicamadas em seu projeto são as seguintes:
- A aplicação se torna mais independente, pois é possível dar manutenção em apenas uma camada sem afetar as demais;
- Garantir a maior segurança do código da aplicação, uma vez que cada camada (servidor) terá um tipo de segurança diferente;
- Economia de licenças de software (por exemplo banco de dados), pois uma camada de banco de dados poderá ser compartilhada com diversos usuários / aplicações;
O desenvolvimento visando a arquitetura multicamadas é uma boa prática, mas cada caso é um caso. Existem cenários que não é vantajoso utilizá-lo:
- Quando é um sistema pequeno que não exige muita segurança devido a sua utilização, a arquitetura multicamadas deixará o projeto mais complexo sem necessidade;
- Quando não se deseja fazer reutilização dos componentes de uma aplicação, a complexidade do projeto também será alta sem necessidade.
Quando você for desenvolver um novo projeto e já definir que ele terá uma arquitetura multicamadas, primeiro análise os requisitos e a complexidade do projeto para depois chegar na conclusão de utilizar ou não a arquitetura multicamadas. Cada aplicação tem uma necessidade e toda satisfação da necessidade gera um custo, garantindo a qualidade e a segurança definida pelo cliente (interno/externo) que solicitou o projeto.
3 Comentários
Realmente alguns iniciantes pode confundir design pattern com arquiteturas de sistemas.
Mas não devemos esquecer que arquiteturas de sistemas de acordo com “Martin fowler” tem que seguir um pattern (Padrões de Lógica de Domínio, Padrões de data source, Padrões comportamentais Objeto-Relacionais, Padrões estruturais Objeto-Relacionais, Padrões mapeamento em metadados Objeto-Relacionais, Padrões de Apresentação WEB, Padrões de Distribuição, Padrões de Concorrência oofline, Padrões de Estado e Sessão, Padrões Básicos).
Assim como um sistema bem desenvolvido devem implementar bons Design Pattern.
Parabéns Bruno, excelente artigo dando uma visão e explicação bem definida.
Olá, Bruno!
Ótimo artigo!
Porém, no meu entendimento, MVC é um Padrão de Arquitetura (assim como o MVP, MVVM, MOVE, etc), e não um Design Pattern.
Design Patterns são propostas de soluções para problemas que ocorrem no contexto do software. Por exemplo, um Adapter que pode ser utilizado para integrar dois módulos ou dois sistemas diferentes e um Observer que pode ser empregado para notificar vários componentes em um evento, evitando várias chamadas de métodos.
Padrões de Arquitetura, por sua vez, definem a estrutura e arquitetura geral do projeto, ou seja, como os conceitos serão separados e manipulados.
O que acha?
Abraço!
Pingback: Arquitetura de sistemas x Design Patterns – UniGeek