Deletado em 7 de agosto de 2009

Programação em N Camadas - MVC - Padrões de Projeto – Parte 1

Depois de um tempinho sem lixo, e algumas cobranças de colegas programadores por novos posts (até minha namorada estava sedenta de atualizações por aqui =P). Gostaria de deletar algo sobre padrões de projetos e/ou criação de soluções OO.

Quem, como eu, já pesquisou sobre programação em camadas pela Web deve ter sentido a falta de informação coerente, pois parece que cada um acaba fazendo do seu jeito, criando nomes diferentes, utilizado frameworks para acertar no padrão e tendo uma visão diferente da necessidade de se programar em camadas.

Bom, jogo no lixo hoje o que entendo sobre padrão de projeto, o motivo de se programar assim e como fazer (na parte 2).

O MVC (Model-View-Controller) e as camadas

Quando aplicamos técnicas de programação orientada a objetos com padrões de desenvolvimento a escrita da linguagem pode se tornar uma ferramenta poderosa para a construção de produtos de software.

O MVC (Model-View-Controller) é um padrão e o C# é a nossa linguagem. Então temos nossas ferramentas para a criação do nosso produto.

E o que diz o MVC?

O MVC diz que, devido à complexidade de grandes aplicações, devemos separa nossas classes de nossos layouts. Assim, independentes, podem ser alterados sem se afetarem.

E como funciona esse padrão?

O MVC tem base a divisão em camadas. Camadas são projetos dentro de uma solução (não são pastas dentro de um projeto). Essas camadas do MVC são as seguintes:

Na imagem acima, no lado do servidor, temos 3 camadas, são elas:

  • View: onde fica a interface do usuário, dados e informações desconhecidas, não tratadas, no caso de aplicações web, são os .aspx, .ascx...;
  • Controller: chamada classe de negócios, onde ficaram nossas regras, verificações, métodos de ação da aplicação e;
  • Model: muito discutida, pois, alguns dizem ser a camada de acesso a dados, outros dizem ser outra camada de negócios (Neste caso onde o Model é considerado outra camada de negócios, mais uma camada é criada, a camada de Persistência, onde no caso, faz acesso aos dados).

A partir deste momento então conhecemos uma prática de padrão de projetos. Sabendo essa prática podemos partir para nossa forma de programação em camadas.

Porque usar camadas na aplicação?

Como vimos no MVC, podemos programar em 3 camadas, ou 4, ou em 5 se formos pensar bem, ou em uma só.

Sim, porque não programar em uma camada só, qual o problema disso?

Nenhum problema desde que você seja o único que vai programar, ou sua aplicação não vai crescer e se tornar um bicho papão.

As camadas ajudam na organização das informações, métodos, objetos, heranças, polimorfismo. Também permite varias mãos em uma só solução, onde vários programadores podem mandar bala em código independente de outro.

Outro ótimo ponto sobre a programação em camadas é que caso algum novo programador for adicionado ao projeto, se o mesmo conhecer pelo menos o MVC (e deve) ele vai ficar por dentro de toda a solução muito mais rapidamente.

Por fim também temos a questão da segurança, já que os níveis de acesso aos dados ficam bem longe das peripécias dos usuários.

E quais são essas camadas?

Podemos usar o MVC? Sim claro é ele o padrão. Mas podemos a partir dele criar o nosso padrão.

Adoro ver esses gráficos que encontramos pela web falando de camadas e tecnologias em geral, então fiz um gráfico explicativo com as camadas que particularmente gosto da fazer e já vi em muitos projetos.

No gráfico acima “powered by A Lixeira do Dri” hehehehe, temos o modelo MVC com três camadas e adicionamos mais uma, a camada de informação.

Vamos entender melhor:

  • Interface (projeto do tipo Web Application ou Windows Application): Camada de apresentação das informações aos usuários;
  • Info (projeto do tipo Class Library): Nesta camada vamos deixar todos nossos objetos (atributos, propriedades), enumeradores e estruturas;
  • Bussines Logic Layer (projeto do tipo Class Library): BLL, nossas regras de negócio, métodos poderosos que sabem de tudo, acessam a classe de dados e fazem acontecer;
  • Data Access Layer (projeto do tipo Class Library): DAO, classe que tem o poder de acessar dados de uma base. Super protegida e persistente.

E seus acessos:

  • A camada de interface acessa a camada de informação para criar/preencher objetos e a camada de negócios para realizar as regras;
  • A camada de negócios acessa a camada de informação para criar/preencher objetos e a camada de dados pra fazer requisições a base de dados;
  • A camada de dados tem acesso apenas a camada de informação para retornar objetos preenchidos ou receber parâmetros dos mesmos;
  • A camada de informação não acessa nada, já que a mesma é acessada por todos.

Nossa solução com os 4 projetos fica dessa maneira:

E como ficam as referências e as classes?

Isso vai ficar para a próxima parte, já que o importante desta parte 1 é entender os porquês e não por a mão na massa.

Até mais!

5 comentários:

Anônimo disse...

gostei bastante da sua explicacao , esta bem simples e facil de entender .
tambem gostei da ideia de "criar o nosso" , aplicando em cima de padroes que ja existem melhorias nossas .

parabens
abraco

Anônimo disse...

Opa!
Parabéns cara ficou muito show de bola a forma que vc escreveu.... Simples e direto ao ponto

Abrass

Anônimo disse...

Opa Adriano!

Cara sua explicação esta ótima parabéns!

Estou ansioso esperando a continuação deste tutorial, pois googlei muito antes de cair aqui e com certeza sua explicação foi a que melhor consegui entender.

Deixo aqui uma dica:

Para a continuação seria ótimo se tivéssemos exemplos em texto SQL no próprio código e outro exemplo do mesmo com stored procedures tbem para fazer os inserts, updades, etc, pois todos os exemplos que achei na net só explicavam através de stored procedures.

Absss,

Att. Marcelo Costa

André M disse...

Muito bom mas... cade a parte 2?????

Adriano Galesso Alves disse...

Desculpe, não estou mais escrevendo. Tavez mais pra frente eu volte.

Mas se fosse escrever uma parte 2 hoje... Faria ass minhas págias .aspx vazias e chamas com JSON para Handlers .ashx, esse por si teriam ações para web services ou fraeworks do jeito que expliquei no post mesmo. Esta funcionando perfeitamente para mim esse tipo de arquitetura.

Valew!
Adriano Galesso Alves

Postar um comentário

Jogue sua opinião na lixeira!

Topo