Infraestrutura de projetos Orientados a Objetos: o MVC

Blábláblá sem tempo, blablabla, não abandonei o blog. Chega de blablabla.

Após falar sobre o Domínio da aplicação, agora vou explicar sobre a infraestrutura – aquilo que faz o sistema funcionar mesmo. Vou escrever sobre o famoso MVC – de Model, View e Controller ou Modelo, Visão(ou apresentação) e Controlador.

Este é talvez o padrão mais comum, é de fato bem simples mas que pode confundir um pouco. Ele trata de dividir a responsabilidades do fluxo de uma aplicação ao atender uma requisição em três camadas básica. Este padrão vem de aplicações desktop, mas vou focar no uso para web.

O Modelo é o já conhecido domínio da aplicação. São os objetos que a aplicação vai lidar.

O Controlador é o responsável por atender uma requisição(ex uma pagina, um formulário) e direcionar o fluxo da aplicação. Ele se comunica com o Modelo diretamente para apresentar ou modificar os dados, e retorna uma Apresentação(view) como resposta para o cliente que fez a requisição, fornecendo a esta Apresentação os dados do Model que precisar.

A Apresentação, é a responsável por montar as telas, templates e a resposta para o cliente. Ele usa os dados vindos do Controlador para montar a resposta.

Então em uma aplicação MVC, ocorre mais ou menos dessa maneira:

  1. O cliente faz uma requisição(um url, por exemplo).

  2. Um controlador padrão, ou através de algum mecanismo é carregado o controlador responsável por esta requisição.

  3. O controlador então decide o que fazer, se necessário atualiza uma informação do modelo.

  4. O controlador pode também passar o controle a um outro/próximo controlador.

  5. Então o controlador carrega a apresentação devida, e lhe fornece os dados do modelo.

  6. A apresentação monta a tela, com os dados vindos do controlador.

  7. A tela é retornada ao cliente.

Básicamente é isto, existem algumas leves váriações de MVC( como o MVP), como aonde o View pode LER diretamente do Model e alguns outros.

Para sequencia o MVC do exemplo, e depois a camada de Banco de dados. 

XML, Atom , Restful webservices e a IBM

Eu acho que já indiquei antes o DeveloperWorks , IBM . É um portal da IBM com muitos recursos para desenvolvedores e várias áreas como sysadmin, modelagem e etc. Lá tem também os Redbooks , muito bons sobre assuntos bem variados. Enfim, quem não conhece, não perca mais tempo.

Eis alguns links que indico, que li esta semana:

Infelizmente esta tudo em inglês, mas para quem puder ler são textos que tem muito acrescentar.

PS: Hoje chegou meu exemplar do Servidores Linux, Guia Prático, do gdhpress.com.br do execelente Morimoto.  Ansioso pela leitura!

Performace e testes de sistemas

Uma prática essencial no desenvolvimento de software é a de testes automatizados, ou desenvolvimento guiado por testes(TDD), e aconselho a todos que pratiquem. É necessário muita força de vontade para começar, mas vale a pena. Eu ainda sou meio preguiçoso, uso sempre nas classes de base(que reuso entre projetos) e nos estudos, mas nos projetos em si geralmente deixo passar várias coisas… shame on me!

Algo legal nos testes por exemplo, é que posso fuçar o funcionamento de alguns frameworks e saber que continuam funcionam, ou dividir uma BFC(Big F*ck1ng Class) em varias e saber que não preciso mudar uma linha no resto da aplicação. 

Um adcional legal nos testes é fazer profilling do código, isto é, analisar o consumo, processamento e possíveis gargalos no fluxo da aplicação. Assim sendo coloco em parte chaves do código(do teste) alguns marcadores para acompanhar o consumo do script. Assim posso testar diferentes implementações de um sistema, com a garantia de que ele continua funcionando e, como bônus, saber qual é a opção mais leve.

Mas uma coisa é fato, Orientação a Objetos (OO) consome recursos! Especialmente memória. Afinal alocar definições de classes, objetos e estruturas de controle mais complexas é algo bem custoso. Sem dúvida que a qualidade do sistema, manutenbilidade(se esta palavra existir) e produtividade valem a pena, mas esse consumo deliberado deve ser observado e controlado.

Algo que constato é que o maior gargalo de sistemas costuma se concentrar em um ou dois métodos apenas, de uma linha de fluxo. Geralmente são métodos mal pensados que fazem queries ruins ao banco de dados ou loops mal formulados(ou ambos). Estes costumam causar o comum problema de tempo de execução e alto uso de cpu do servidor, causando lentidão no sistema.

Voltando a memória, alocar muitos objetos, cheios de informações inúteis, muitas classes não utilizadas, devido às muitas camadas, aos recursos muito genéricos e etc de um sistema costumam e que ficam presos do inicio ao fim da aplicação costumam ser os vilões.

Claro que vale a pena usar frameworks, desenvolver em camadas e tudo mais, mas é bom desenhar bem sua aplicação e fazer constantes testes e profiling do sistema como um todo, principalmente usando testes mais reais(e um banco de dados cheio).

Não era sobre isso que ia escrever, mas esta bom assim. É isso!

Orientação a Objetos: Modelando o Negócio

Para começar a série sobre conceitos e design de sistemas, preciso repassar sobre um assunto de programação: Orientação a Objetos. E serei breve.

Modelar um sistema usando orientação a objetos(OO) consiste em passar objetos do mundo real para o virtual. Neste caso cada objeto do sistema virtual representa um objeto do sistema real.

Normalmente usamos Classes ou Protótipos(ou outros) para definir padrões para os objetos, na implementação, são a abstração destes. É interessante conhecer sobre análise de requisitos, UML ou qualquer técnica de especificações para começar a modelar OO.

Vamos ao exemplo:

Num sistema vendas, uma loja virtual, que objetos temos? Levantando os requisitos básicos do sistema(super simplificado):

Um visitante acessa a loja virtual, lhe é apresentado uma lista com as categorias de produtos que a loja oferece. Ao escolher uma categoria ele tem agora os vários produtos desta categoria para escolher, ele pode clicar em um produto para ver seus detalhes. O Visitante pode adicionar os produtos ao carrinho, escolhendo a quantidade. Quando estiver escolhido todos os produtos o visitante pode finilizar sua compra, para isso ele precisa de um registro no site para logar-se como usuário. Ele pode também se cadastrar criando um usuário com seus dados. Com o carrinho pronto o usuário pode finalizar sua compra, isto ira gerar um pedido para a área de vendas.

Sem entrar em detalhes de fluxos e etc, a partir deste brief podemos extrair alguns objetos do sistema.
O Visitante pode ser um objeto, temos também o Usuário. Temos ainda Categoria, que vão conter Produtos. Temos o Carrinho de Compras, que contêm produtos escolhidos, e que ao final gera um Pedido de Usuário.

– Visitante
– Usuário
– Categoria
– Produto
– Carrinho de Compras
– Pedido de Usuário

Estes objetos são o DOMÍNIO do sistema de Loja virtual, são o modelo do sistema. É em cima destes objetos e suas relações que todo o sistema vai trabalhar. E as relações deles:

Uma Categoria possui "n" produtos. Um Produto pode esta associado a mais de uma categoria. Um carrinho também possui produtos. Um Pedido é gerado ao fechar um carrinho, e pertence ao usuário que o criou. Um usuário por sua vez, possui todos os pedido que gerou.

Objetos possuem atributos. Atributos são o ESTADO deste objeto. O próximo passo é descobrir os atributos destes objetos. Para isso precisaríamos estender um pouco nosso briefing anterior, mas para agilizar vamos ao senso comum(nunca usado em projetos reais rsrs):

– Usuário
    Nome
    Email
    CPF
    Senha
    Endereço

– Categoria
    Nome

– Produto
    Nome
    Preço unitário
    Peso

– Carrinho De Compras
    Data

– Pedido De Usuário
    Data

Foram omitidos os atributos das relações, que ficará assim, agora um belo diagrama UML:

[[inserir diagrama simples aqui quando chegar em casa]]

Essa é a modelagem do Domínio da aplicação, esse é o negócio do sistema. Estes objetos possuem ainda COMPORTAMENTO, que são os métodos que estes implementam. Esses objetos não possuem nenhum comportamento especial, mas podemos colocar métodos como adcionarProduto e calcularTotal no Carrinho.

Tratando de objetos de negócio, nós temos ainda duas opções de como implementa-las. Com atributos públicos ou privados(ou protegidos). Deixando os atributos públicos, o acesso é direto ao atributo, livremente. Usando atributos privados, seguimos com um padrão chamado de Bean, que temos getters e setters para cada atributo que precise ser acessado(Ex.: getNome, setNome…).

Manter os atributos públicos a princípio parece mais prático, mas na minha opnião o padrão Bean permite maior controle sobre o comportamento do Objeto, sem gambiarras.

[[inserir diagrama completo aqui quando chegar em casa]]

Obviamente só com isso um sistema não funciona, é preciso ter paginas, formulários, banco de dados, etc etc. Essas outras partes do sistema, a infraestrutura, são da parte de implementação e vou trata-las nos próximos textos.

Criticas são bem vindas.

Até.

Programação para programadores

Bom, o tempo esta escasso e as postagens também. Então para animar um pouco mais as coisas vou escrever sobre um assunto que sempre quis falar: Programação.

Não vou tratar de algorimos, estruturas e linguagens, mas vou defender temas muito mais divertidos como Orientação a Objetos, que espero que todos conheçam pois vou falar pouco, e temas de modelagem e arquitetura de aplicações. E o que isso quer dizer? Isso :

  1. MVC – O famos model, view e controller
  2. MVC2 – Remformulação do padrão
  3. MVP – DEu para entender…
  4. DAO e ActiveRecord – Padrões para persistencia de dados
  5. Repository – Padrão para acesso a dados
  6. Para então, vir o melhor: DDD – Domain driven design

São todos assuntos relativos a design de software, para os quais terei de tratar outros assuntos como pré-requesitos. Pretendo citar framework e exemplos, mais vou evitar me prender as linguagens, elas serão coadjuvantes.

No proximo espero já começar com uma rápida intro sobre OO(responsabilidade, baixo acoplamento…).

É isso!