O desenvolvimento de aplicações utilizando o MVC Framework, da Microsoft, juntamente com o ASP.NET ou tecnologias similares tem crescido bastante nos últimos anos. Trata-se de uma tecnologia com vantagens interessantes sobre outras, como o fato de ser um framework consolidado e que permite uma organização muito clara do projeto de software. Entretanto, o ASP.NET MVC ou outros, sozinhos, não resolvem tudo. É importante que apliquemos os chamados design patterns em nossas aplicações, para garantir que as melhores práticas de programação sejam obedecidas, e que qualquer programador que leia o código o entenda e melhore, se necessário.
O conceito de design patterns é global. Tratam-se de técnicas aplicáveis a qualquer linguagem de programação e plataforma-alvo, ou seja, são conhecimentos universais para qualquer desenvolvedor de software e devemos aprender ao menos os mais importantes para construir nossas aplicações.
Ao longo desse artigo conheceremos os principais padrões de projeto da camada de negócios da aplicação, que vem de um conceito muito útil e comum em softwares comerciais, que é o desenvolvimento em camadas. A ideia é que tenhamos, separadamente, detalhes como as regras do negócio, o acesso a dados, a apresentação do produto e os serviços que o mesmo utiliza. As camadas não são restritas a apenas essas, e poderíamos criar vários artigos para explicá-las, entretanto, o foco deste artigo é nos padrões de projeto da camada de negócios, com quatro em especial: Factory, Decorator, State e Strategy.
A camada de negócios
O desenvolvimento de software em camadas, além de uma realidade, é uma necessidade atualmente. Com a elevada complexidade nos projetos de software não é viável que todas as peças do sistema estejam misturadas. Isso criaria uma montanha de códigos que ninguém conseguiria decifrar. É nesse contexto que entra essa abordagem de desenvolvimento, como mostra a Figura 1. Essa imagem mostra a divisão mais comum no desenvolvimento de software. Note que existem diversas camadas e cada uma tem sua responsabilidade dentro do software. Neste artigo trabalharemos com a de negócios, representada pelo modelo de domínio, juntamente com a de serviços (serviços de domínio).
Figura 1. Arquitetura típica de aplicação em camadas
Um detalhe importante no conceito de desenvolvimento em camadas é a comunicação entre as diferentes partes da aplicação. Essa comunicação precisa ser rápida e confiável, caso contrário a experiência do usuário será seriamente prejudicada. Existem algumas formas de lidarmos com essa comunicação, mas no geral isso é tirado das mãos do programador. No caso do desenvolvimento .NET, o Visual Studio facilita muito a nossa vida nesse aspecto.
Assim como qualquer camada, a de negócios possui padrões de alguns tipos base: organizacionais, comportamentais, criacionais e estruturais. Cada tipo comanda uma área específica no desenvolvimento de software, como o nome sugere. Os padrões organizacionais não serão vistos ao longo do artigo, mas podemos destacar alguns, como o Transaction Script (BOX 1) e o Domain Model (BOX 2). Ambos são muito utilizados e possuem seus respectivos nichos. No caso de aplicações comerciais, o Domain Model é o mais comum, sendo muito utilizado com ORMs como o Entity Framework e o NHibernate.
O Transaction Script é considerado o mais simples padrão organizacional da camada de negócios. Esse padrão é procedural, e não orientado a objetos, o que pode dificultar sua utilização em aplicações OO. Entretanto, nada impede essa utilização. A ideia por trás desse padrão é criar um procedimento para cada transação do negócio da aplicação, sendo que cada procedimento contém todas as regras de negócio, validação e fluxo de trabalho necessárias para o bom funcionamento das transações.
O modelo de domínio, ou Domain Model, é muito utilizado em diversas aplicações, especialmente aquelas que são centradas em dados. A facilidade de utilização com padrões de acesso a dados como o Repository e o Unit of Work é uma grande vantagem neste caso. A ideia é que tenhamos classes para representar os objetos que armazenaremos dentro da aplicação, como uma Pessoa ou uma Escola. Esse padrão incrementa os dados e o comportamento de cada uma das entidades. Existe uma versão chamada de Anemic Domain Model, que traz objetos contendo apenas a representação dos dados, sem qualquer comportamento. Trata-se de uma abordagem interessante quando lidamos com bases de dados através de ORMs.
Mas, afinal, o que é a camada de negócios? Imagine o local onde todas as informações sobre o negócio da empresa estarão representadas. É disso que tratamos aqui. Cada aplicação possui uma regra de negócio clara: é ela que especifica o que a aplicação fará e como isso será feito. Essa camada é uma das mais importantes e complexas da aplicação, normalmente, uma vez que contém o “cérebro” da mesma. Todos os comportamentos básicos da aplicação devem estar presentes nessa camada.
Assim, a camada de negócios deve ser levada muito a sério, e testada exaustivamente utilizando testes unitários e outros para garantir que os comportamentos definidos aqui estão corretos. E, é claro, é importante que haja um entendimento das necessidades do cliente com relação à aplicação para garantir que a camada sairá correta. Por fim, é fundamental que todos os padrões necessários sejam utilizados para facilitar na hora de renovar a aplicação ou mesmo adicionar novas funcionalidades, além de garantir maior desempenho ou confiabilidade à mesma.
Padrões da camada de negócios
São vários os design patterns que podem ser aplicados nesta e em outras camadas
da aplicação, no entanto, neste artigo daremos um foco maior nos padrões
comportamentais (State e Strategy), criacionais (Factory) e estruturais (Decorator). Essa classificação é obtida
baseada nas funcionalidades que esses padrões implementam e como eles fazem
isso. Cada um tem seu nicho dentro da aplicação e podem ser utilizados para
c ...
