Há certo tempo recebi dois e-mails sobre com alguns questionamentos sobre MVC, que hoje em dia tem sido muito falado por todos (principalmente pelo programadores de .NET). O objetivo deste post é tentar esclarecer o que é o Design Patterns (Padrões de Projeto) MVC.

Bom, MVC significa Model, View e Controller. A ideia básica do MVC é de separar a lógica de negócio da apresentação (muito semelhante ao modelo de 3 Camadas. Bom, posso estar enganado e se estiver por favor comentem pois este é o objetivo). Vamos entender o que significa própriamente cada uma da letras.

M (Model)

Esta “camada” representa os dados da aplicação e as regras de negócio do acesso e modificação desses dados. Ela é quem fornece ao controlador a capacidade de acessar as funcionalidades da aplicação(Insert, Update, Delete).

Ultimamente tenho lido alguns forúns (alguns bem antigos por sinal) e percebi uma certa discussão sobre o que deve ficar no Model. Alguns dizem que a regra de negócio deve ficar no Model, mas eu particularmente acho bem mais interessante deixar o Model como sendo a DAL. Uma “camada” onde são tratadas as ações de Insert, Update, Delete e Select.

V (View)

As Views servem apenas para exibir as informações. São elas que renderizam o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário. A View também acessa os dados do modelo através do controlador (Controller) e determina como esses dados devem ser apresentados.

Bom, comparando ainda com o modelo 3-tier (3 Camadas) essa seria a Interface.

C (Controller)

O controller define o comportamento da aplicação, é ele que interpreta as ações do usuário (View) e as mapeia para chamadas do modelo (Model).

Aqui sim ficaria a regra de negócio do nosso projeto. Grande partes dos post que li, tem colocado o controller como uma “gatilho” que serve apenas para disparar e identificar quais ações devem ser executadas no Model, mas para mim o Controller seria nossa BLL do modelo 3-tier.

Bom, é claro que esse é meu ponto de visto sobre como se pode utilizar este modelo.

Aqui estou apresentando uma imagem baseada em um modelo que realmente não me lembro onde vi. Ela mostra como são realizadas as requisições:

1 - O usuário realiza uma requisição de uma View (página web) ao Controller. Ex: Preenchimento do formulário de cadastro.

2 - O Controller recupera todas as informações da View e solicita uma ação (Insert por exemplo) para o Model. O Model processa a ação (grava em banco de dados) e devolve o resultado deste processamento para o Controller.

3 - O Controller processa o resultado e devolve para View o que ela deve exibir.

4 - A View recebe o que foi processado pelo Controller e exibe o resultado para o usuário. (Enteda a View como a página exibida) Ex: Imaginando um cadastro que foi realizado com sucesso, o retorno pode ser uma Mensagem de Sucesso.

Em resumo o modelo MVC é muito usado em aplicações para  Web, onde a View é a página  HTML, o controller é quem gera os dados dinâmicos para dentro da View (HTML) e o Model é representado pelo manutenção dos dados, ou seja, armazenagem em BD ou outros tipos de arquivos.

Bom, espero que com este post eu possa ter esclarecido um pouco como funciona esse Design Pattern. A idéia é simples mas pode confundir um pouco, mas nada uma boa leitura não ajude.

Em breve tem mais.

Depois de um bom tempo sem escrever sobre POO, vamos continuar falando sobre os conceitos: Herança, Polimorfismo e Encapsulamento.

Herança

Esse é um dos principais conceitos da POO. A herança é o compartilhamento de atributos e operações entre classes com base em relações hierárquicas, ou seja, é a utilização de superclasses para criar as subclasses.

Veja o exemplo abaixo:

Aqui representamos a classe Carro e as subclasse GOL e Ferrari.

Polimorfismo

Polimorfismo é conceito ou melhor é a capacidade que um mesmo método pode se comportar de diferentes maneiras em diferentes classes. Enquanto a herança é voltada mais as classes, o polimorfismo está voltado aos métodos.

Imagine o método Correr na classe Carro. Agora imagine o mesmo método na subclasse GOL e na subclasse Ferrari. Em cada subclasse o método irá se comportar de maneira diferentes.

Encapsulamento

Esse conceito consiste em esconder os detalhes de implementação das Classes. O encapsulamento permite definir a visibilidade dos elementos de uma classe e essa visibilidade controla os acesso aos dados e métodos.

• Privada: pode ser usado apenas pela classe que o define.
• Protegida: pode ser usado pela classe que o define e por qualquer subclasse da classe que o define.
• Pública: pode ser usado por qualquer objeto no sistema.

Bom, com isso finalizamos este post.

Em breve tem mais e espero que tenham gostado.

Dando sequência a série de post’s sobre POO iremos abordar agora sobre conceitos essenciais da POO e para falar sobre esse assunto irei dividi-lo nas seguintes partes:

• Objeto;
• Herança;
• Encapsulamento;
• Polimorfismo;
• Classes;
• Relacionamentos;
  • Agregação;
  • Generalização;
  • Associações N(Árias)
  • Abstração

Neste post iremos detalhar os seguintes itens: Classe e Objeto, já no próximo post serão descritos os itens: Herança, Encapsulamento e Polimorfismo e os demais itens em sequência.

No post Programação Orientada a Objeto - O início nós já percebemos que a POO, veio para auxiliar a solução de problemas, através da modelagem do problema no meio computacional. Essa modelagem é feita através de objetos.

Nosso mundo é composto por objetos e cabe a nós desenvolvedores entendermos quais são os objetos necessários na resolução de um determinado problema.

Bom, mas como definimos um objeto? Basta dizer que um objeto é do tipo de uma determinada classe.

Antes que isso fique complicado, vamos tentar explicar de uma forma mais simples a idéia básica do assunto.

Primeiro definimos quais são as classes do nosso sistema (Ex: Carro, Pessoa, Movimento). Assim que as classes forem definidas podemos utilizar os itens herança e polimorfismo para conseguirmos um melhor mapeamento dessas classes. A partir do momento em que você utiliza classes para criar uma instância da mesma (Ex: Carro meuCarro = new Carro() - a sintaxe não é a mesma para qualquer linguagem de programação), então você tem um objeto de um determinado tipo, neste caso um objeto do tipo Carro.

Vamos agora detalhar um pouco mais cada um desses itens.

Classe

No mundo atual existem carros e cada carro possui uma particularidade, mas todos possuem a mesma estrutura e comportamento. A definição de um modelo que descreve essa estrutura e esses comportamentos é nomeado como uma Classe.

Por exemplo, a classe Carro possui a estrutura com: cor, altura, comprimento. Os comportamentos que um carro pode ter são: andar(), virarDireita(), virarEsquerda(), parar().

Objeto

Uma vez definida a classe do tipo Carro, fica mais fácil criar objetos que utilizem desta mesma estrutura. Basta instanciar N objetos do tipo Carro que teremos, carros diferentes, porém, com estrutura e comportamento iguais.

O objeto é alguma coisa com limites bem definidos e significados bem claros dentro de uma aplicação, ou seja, é a instancia de alguma classe.

Grady Booch colocou uma definição para objeto: “Um objeto possui um Estado, Comportamento e uma Identidade”.

Entendendo esses 3 pontos:

1. Identidade: Todo objeto possui uma identidade. Por exemplo, um novo objeto - Carro meuCarro = new Carro() - é um objeto com a identidade meuCarro;
2. Estado: O estado são as estruturas de um objeto. Por exemplo, o objeto meuCarro possui o atributo cor. Quando definimos um valor para esse atributo, nós definimos isso como estado. meuCarro.cor = Azul;
3. Comportamento: Acima, nós também vimos os comportamentos de um objeto (andar, virarDireita). Quando nós chamamos esses ‘métodos’ de um objeto, ele realiza a ação que lhe foi solicitada. meuCarro.virarDireita();

Fechamos assim a descrição desses 2 pontos que são de muita importância na POO. É claro que estes conceitos são bem básicos, até mesmo porque esse assunto é bastante complexo.

Em breve estarei falando um pouco de Herança, Polimorfismo e Encapsulamento.

Até o próximo post.

Hoje vou iniciar uma série de post’s que tem como objetivo introduzir os conceitos básicos de POO (Programação Orientada a Objeto), a plataforma .NET e em sequência alguns pontos mais avançados sobre esses assuntos.

Vou escrever essa série de post’s em virtude do meu trabalho (não posso entrar em detalhes agora, mas irei dar notícias a todos em breve). O principal foco dos post’s serão desenvolvedores que desconhecem programação orientada a objeto.

Não irei abordar neste post os conceitos de POO como Objeto, Herança e Classe, porque antes de entrar em detalhes sobre esses pontos, primeiro devemos entender o porque do surgimento da POO.

O início da POO

Um dos criadores deste conceito de linguagem de programação foi Alan Kay, também conhecido por ter criado a linguagem de programação Smalltalk.

A criação deste conceito se deve em grande parte as linguagens de programação mais antigas como Fortran, C, Pascal também conhecidas como linguagens de programação procedimentais, ou seja, imagine uma lista de instruções onde cada linha que é executada realiza uma tarefa, por exemplo, cria uma variável, adiciona uma valor a variável, exibe um resultado.

Esse contexto em uma situação onde se tem um sistema pequeno, talvez não seja um problema, mas a medida que o sistema cresce e consequentemente a lista de instruções cresce, a execução/manutenção desta lista poderá se tornar uma tarefa um tanto quanto difícil.

Uma tentativa de minizar o problema é dividir o código do sistema em pequenas partes, denominadas de funções. A quebra do código em funções e o agrupamento dessas funções pela semelhança de suas ações, são um dos fundamentos da programação estruturada e até mesmo este paradigma de programação mostra limitações a medida que o sistema cresce.

Com esse problema surgiu a necessidade da criação de uma linguagem de programação que resolvesse este problema. Aí surge o conceito de POO.

O problema e a solução

Bom, então já temos um problema: Situações que requerem um sistema um tanto quanto robusto e grande, possuem problemas para implementação de soluções com as linguagens de programação procedimentais ou pela programação estruturada. Então como resolver isso?

A utilização de programação orientada a objeto ou como alguns chamam modelagem orientada a objeto requer a identificação deste problema e o mapeamento da solução na forma de objetos.

A POO foi criada com o objetivo de tentar aproximar ao máximo o mudo real do mundo computacional. Mas como isso é feito? Mapeando todos os objetos.

O nosso mundo é constituído de objetos e esses objetos possuem estados, comportamentos e cada um tem sua própria identidade. A POO vem para auxiliar na descrição dos objetos de um problema da forma real, para a forma computacional.

Bom, então podemos definir como a principal característica da programação orientada a objeto a modelagem de um problema do mundo real, para um mapeamento dos objetos destes problemas no mundo computacional, visando facilitar a criação de uma solução.

Bom, espero que tenham gostado.