Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Da aplicação do padrão de projeto Abstract Factory em um sistema para extração de relatórios customizados, que deverá permitir ao usuário executar uma consulta e exportar o resultado para determinados formatos, também enviá-los para clientes de diversas maneiras.
Para que serve
Desacoplamanento entre camadas, remoção de dependências entre produtor/consumidor, interfaceamento simplificado, redução de retrabalho e reaproveitamento de código.
Em que situação o tema é útil
Em cenários onde se vê presente times distribuídos, escopo não muito bem definido, sistemas com alterações frequentes, e situações semelhantes.
Não é muito eficiente nestes casos, modelarmos banco de dados (ou outra ferramenta para persistência de dados), nem escrever classes de regras de negócios ou camadas de acesso a dados, antes de termos as GUIs ou Serviços expostos criados e validados pelo cliente final.
O assunto tratado por este artigo poderá ajudá-lo a evitar que este tipo de situação comprometa o resultado final e o prazo de entrega do seu projeto.
Resumo do DevMan
Este artigo abordará um tema não muito novo e até relativamente comum em outras comunidades, porém pouco falado no cotidiano do mundo Microsoft. Utilização de design patterns em C#, mais especificamente no desacoplamento de camadas. Para isso utilizaremos os Design Patterns Abstract Factory, Factory e Facade, visando aumentar a produtividade no desenvolvimento de software com equipes distribuídas, reduzindo retrabalho nas camadas de lógica de negócios, acesso a dados e modelagem do sistema de persistência (banco de dados, nuvem, arquivos etc.) e aumentando a flexibilidade da aplicação.Tecnologias/Conceitos utilizados: C# 3.0, Orientação a Objetos, Design Patterns, UML, Engenharia de Software.
No desenvolvimento de aplicações, sejam elas a partir do zero ou melhorias/redesenvolvimento de uma ferramenta já existente, via de regra as empresas onde as mesmas são desenvolvidas seguem uma “receita de bolo” para se chegar ao “o que vamos fazer” e efetivamente começar a executar as tarefas que levam ao resultado de um projeto.
Quero apresentar um conceito que todo mundo na nossa área já ouviu falar pelo menos uma vez, fazendo algumas modificações para extrair o melhor dele. Vamos utilizar o famoso modelo de desenvolvimento em camadas, mas para termos uma flexibilidade real, precisamos que ele realmente nos dê algo a mais.
O que vamos fazer é pensar da seguinte maneira: e se a gente estendesse este conceito de “N-Camadas” e fizesse com que as camadas de apresentação e regras de negócio do nosso sistema fossem realmente separadas, fisicamente sem referências, com baixo acoplamento de verdade? E mais: se incluíssemos alguma “coisa” entre elas, uma camada responsável por chamar as regras de negócio necessárias a cada módulo. Isto poderia propiciar um ambiente onde pudéssemos ter uma camada de regras de negócio “falsa”, codificada para preencher os campos da maneira mais rápida possível. Esta camada permitiria que os desenvolvedores mantivessem o foco primeiro em modelar o problema em entidades e logo em seguida desenvolver os módulos visíveis do sistema. Estes normalmente dão ao usuário final uma ideia melhor do que está sendo feito. Esta ação permitiria a obtenção de feedbacks mais rapidamente e com menor custo para alterações.
Seguindo esta ideia faríamos controles de validação de tela, chamadas a Web Service, controles de usuário, controles customizados etc. Não teríamos que efetivamente dedicar tempo à construção das camadas de Regras de Negócio, Acesso a Dados e todo o trabalho que deve ser realizado, por exemplo, no banco de dados (modelagem relacional das tabelas, criação de stored procedures). Já imaginou obter feedbacks do cliente depois de todas estas árduas tarefas estarem completas, ou seja, arriscando ter que mudar tudo isso em caso de umas modificações exigidas durante o desenvolvimento ou pior ainda, se requisitos são alterados completamente.
Outra grande vantagem: Caso você tenha certeza que seus requisitos não vão mudar, você poderia facilmente ter times distintos trabalhando em interface com o usuário e outro com regras de negócio/acesso a dados completamente separados sem afetar uns aos outros até a fase de integração.
...
