Artigo .net Magazine 58 - Aplicação Web Corporativa

Boas práticas - Expert

Aplicação web corporativa

Melhores práticas em uma aplicação web de verdade com MVC e Entity Framework

Qual a melhor estrutura para uma solução? Quais os melhores padrões de arquitetura para determinado cenário? Qual  estratégia de tratamento de erros utilizar em tal aplicativo? Quais design patterns (padrões de projeto) se encaixam melhor nos requisitos levantado? Estas são apenas algumas perguntas com que nos deparamos quando iniciamos o desenvolvimento de um aplicativo. São perguntas que o arquiteto de software deve responder, e, se respondidas de maneira errada, ou sem visão de futuro, podem levar ao fracasso do projeto.

Neste artigo vou demonstrar a montagem de uma aplicação em que as preocupações reais do dia a dia do negócio serão atendidas. São requisitos reais, que um artigo focado em tecnologia não consegue normalmente atender. O foco deste artigo será atender requisitos que você recebe na montagem de uma aplicação real. Alguns pontos abordados serão:

1.     Qual estratégia de mapeamento objeto/relacional utilizar;

2.     Como montar uma estratégia de tratamento de erros eficiente;

3.     Como preparar a aplicação para aceitar mudanças de maneira flexível, sem obrigar que todo o código seja revisado ou refeito, mas apenas as partes envolvidas;

Todas estas perguntas serão respondidas diante de um cenário, que vou apresentar em seguida. Como se trata de uma aplicação Web, adotaremos o Beta do ASP.Net MVC como front-end (depois você verá porque), e utilizaremos Entity Framework (EF) para obter os dados.

A aplicação

Construiremos uma aplicação de e-commerce, ao estilo E-Bay, onde um usuário pode colocar um produto próprio para vender, e outro usuário pode comprá-lo. Toda aplicação precisa de uma análise do negócio, ou seja, precisa definir seu domínio. Diante disso, os seguintes casos de uso serão atendidos:

1.    Cadastrar-se no site;

2.    Logar no site;

3.    Exibir produtos à venda;

4.    Cadastrar um produto para vender, sendo possível cadastrar produtos do tipo livro ou veículo;

5.    Criar uma veiculação para um produto;

6.    Pagar por uma veiculação;

7.    Exibir um produto para possível compra

8.    Fazer a proposta de compra de um produto;

9.    Exibir propostas de compra para o vendedor do produto;

10.Aceitar ou rejeitar as propostas de compras;

11.Exibir os erros da aplicação.

As Figuras de 1 a 3 mostram os diagramas destes casos de uso. Atente para os números dos casos de uso, porque eles serão utilizados ao longo do artigo.

Figura 1. Atores do sistema

Figura 2. Atores “Usuário” e “Comprador” e seus casos de uso

Figura 3. Ator “Vendedor” e seus casos de uso

O aplicativo funcionará da seguinte forma: o usuário acessa o aplicativo, onde vê a página inicial da aplicação, conforme Figura 4. Neste caso, note que o usuário já está logado (veja no canto superior direito na tela o login apresentado), e pode ver os produtos à venda na área principal da aplicação (caso de uso número 3), assim como os produtos que precisam ser verificados, pois têm proposta de vendas, na parte inferior da aplicação (caso de uso número 9).

Figura 4. Home page da aplicação

O usuário poderá então, cadastrar produtos. Ele o faz clicando na aba “Meus produtos”, no canto superior direito, onde a tela apresentada na Figura 5 é exibida. Note que todos os seus produtos são exibidos, possibilitando editar os produtos existentes ou cadastrar um novo (caso de uso número 4). Novamente é exibida a lista de produtos com solicitação de compra, na parte inferior da aplicação (caso de uso número 9).

Figura 5. Tela de produtos

Ao clicar no link de incluir produtos, o usuário é direcionado à tela de inclusão. Além de ser possível incluir livros, é também possível cadastrar produtos do tipo veículos. Em ambos os casos, se algum campo não for informado, ou for inválido, um erro deve ser apresentado, conforme a Figura 6, que apresenta a tela de cadastro de veículos com um erro por falta de preenchimento de campos obrigatórios. A tela de cadastro de livros é semelhante, contendo campos para editora e autor, entre outros.

Figura 6. Cadastrando um veículo: há campos obrigatórios

Após cadastrado o produto, o usuário é direcionado a uma tela onde pode criar uma veiculação para o produto (caso de uso número 5), conforme exibido na Figura 7, onde as veiculações são listadas. Note que é possível cadastrar mais de uma veiculação por produto, e que a tabela exibe os pagamentos da veiculação em uma das colunas.

É feito então o pagamento da veiculação, conforme exibido na Figura 8, onde se vê a tela de pagamento (caso de uso número 6). Neste caso trata-se de um pagamento de cartão de crédito, mas poderia ser um pagamento feito com boleto, onde a tela de pagamento é um pouco diferente. Após o pagamento o produto passa a ser exibido na home page da aplicação, na coluna apropriada.

Figura 7. Exibindo as veiculações e seus pagamentos

Figura 8. Realizando o pagamento com cartão de crédito

Caso um usuário se interesse por um produto, ele clica sobre o produto exibido na Figura 4, e uma tela de exibição de detalhes do produto é exibida (caso de uso número 7). Pode então solicitar a compra (caso de uso número 8), e uma tela é exibida com os dados do produto. O usuário comprador pode então clicar em um botão de confirmação de proposta de compra, e o produto é marcado para que o vendedor possa aprovar a compra. O vendedor então poderá verificar quem é o comprador e aprovar ou rejeitar a venda (caso de uso número 10) em uma tela simples com um botão de aprovar ou rejeitar a proposta.

Há ainda a possibilidade de ocorrer um erro na aplicação (caso de uso número 11). Para ver os erros logados, o usuário poderá clicar na aba de erros, no canto superior direito da tela da aplicação (veja na Figura 4), e então uma lista de erros não tratados será exibida, conforme a Figura 9. Apenas os erros não tratados, ou seja, bugs, serão reportados nesta página. Quando um bug acontecer, além da realização do log, a view padrão de exibição de erros do ASP.Net MVC será exibida.

Figura 9. Lista de erros

O login (caso de uso número 2) é feito da maneira usual do ASP.Net MVC, sem mudanças. Já o cadastro do usuário foi alterado (caso de uso número 1), conforme a Figura 10, para incluir as propriedades nome e sobrenome, que não estão presentes normalmente no ASP.Net MVC. Mais a frente veremos como fazer para armazenas essas informações, mas já adianto que utilizamos os profiles do ASP.Net, mas sem quebrar as regras de encapsulamento e mantendo um padrão de repositório.

Figura 10. Cadastro de usuário

Esse é o cenário que iremos atender. Obviamente não compreende todas as funções de um site de compra e venda profissional, mas atende as operações mais importantes de toda a aplicação, como as operações CRUD, e regras de negócios complexas. Existem interações interessantes, onde precisaremos obter objetos que dependem uns dos outros, fazer buscas de acordo com determinado critério, especificado por um objeto, e até operações que envolvem aplicativos externos ao sistema que está sendo desenvolvido, como as operações de pagamento, que devem se integrar com um aplicativo bancário.

Mais importante do que o negócio apresentado até este instante, ou as regras de negócio apresentadas a seguir, são os padrões aplicados a cada situação. Explicarei os pontos onde os padrões são aplicados na prática e porque foram escolhidos.

Visão de futuro

Antes de prosseguirmos na solução proposta, vamos abordar os motivos que nos levam a montar uma arquitetura mais complexa. Não seria necessário montar uma arquitetura focada em melhores práticas se acreditássemos que a solução teria somente os requisitos apresentados até aqui. Preparamos uma arquitetura fundada em padrões reconhecidos justamente porque sabemos que a aplicação não vai manter os mesmos requisitos durante toda sua existência. Na verdade, aplicativos do mundo real não mantêm os mesmos requisitos nem mesmo durante o desenvolvimento do projeto inicial, quem diria ao longo de toda sua existência.

Durante toda a vida do aplicativo, o mesmo deverá passar o teste mais difícil de todos: o tempo. A média de investimento em TI de uma empresa, cujo negócio principal não é TI, fica entre 70% e 80% para manutenção de software, e somente o restante para criação de software novos. Isso significa que a maior parte deste investimento vai na manutenção do legado. E só de ouvir a palavra “legado”, muitos já se assustam, porque muitas vezes significa código difícil de manter (às vezes impossível). É esse desafio que uma arquitetura bem montada quer vencer.

Dito isto, nas consultorias de arquitetura que realizo, sempre recomendo que os padrões sejam utilizados, mesmo para aplicações muito pequenas. É muito comum empresas ou usuários afirmarem que um aplicativo é pequeno, não vai ter muitas atribuições, não será alterado no futuro, ou ainda que terá vida curta. É também muito comum que estes aplicativos sobrevivam por muito tempo, não sejam substituídos, e, pior de tudo, cresçam desordenadamente. Já perdi a conta de quantas vezes encontrei um aplicativo, que era para ser um simples aplicativo CRUD e foi desenvolvido na base do “arrastar e soltar”, funcionando depois de anos do que era esperado, e depois de diversas atualizações, onde agora vivem regras de negócios complexas e às vezes fundamentais para o dia a dia da empresa. Não caia nesse erro.

Se este projeto fosse um projeto do mundo real eu também recomendaria que fosse desenvolvido aplicando um ciclo de desenvolvimento ágil, de forma a garantir que os requisitos seriam implementados o mais próximo possível da realidade. O tipo de arquitetura que será montada ao longo deste artigo, baseada em DDD, como veremos a seguir, e que abraça as mudanças de forma muito flexível (ao invés do mais comum: brigar com as mudanças), facilita muito o desenvolvimento no modelo ágil, e é recomendado pela maior parte dos praticantes do Domain Driven Design.

Camadas: Tiers e Layers

Vou começar apresentando as camadas da aplicação. O desenho das camadas está exposto na Figura 11. Em inglês o termo camada pode ser traduzido como tier, que tem significado que se aproxima mais de camadas físicas, ou como layer, que significa camadas lógicas. Neste caso, estamos vendo uma mistura das duas. Isso não é um problema uma vez que o foco do diagrama é passar uma informação, e de nada adiantaria um diagrama que focasse em tiers ou layers, mas ficasse incompleto. Diante deste foco: resolver um problema, o diagrama atende às necessidades que motivaram sua criação." [...] continue lendo...