O artigo aborda a arquitetura do Prism 4.0, que é um framework para criação de aplicações compostas. Utilizaremos o Silverlight como tecnologia cliente, mas poderia até mesmo ser o WPF a tecnologia escolhida. Entenderemos os patterns no qual se baseia a implementação deste framework.
Em que situação o tema é útil
No desenvolvimento de sistemas que atendam a alguma linha de negócio, que sofram constantes mudanças, exigindo assim uma arquitetura flexível e aderente à adição de novas telas ou até mesmo funcionalidades com o mínimo de impacto possível, e muitas vezes sem parar a aplicação.
Prism
Aplicativos de linha de negócio ou, como são comumente chamados, Line of Business (LOB) atendem aos mais diversos setores e ramos de negócio. E dependendo do objetivo do aplicativo, ou o negócio ao qual ele irá atender, a ocorrência de mudanças no software é alta. Quando se trabalha em cenários como este, decisões arquiteturais devem ser bem pensadas para viabilizar a construção de um sistema que seja aderente a mudanças, com um mínimo de impacto possível. Atualmente temos algumas tecnologias e patterns, que são poderosas ferramentas na hora de encararmos este tipo de desafio. A Microsoft tem o que chamamos de Composite Application Library (CAL), sob o qual o Prism se fundamenta. Aplicações construídas sobre o conceito de composição nos permitem ter aplicativos que se compõem em tempo de execução. O Prism em conjunto com o Silverlight, forma uma excelente combinação para produzir aplicações robustas, aderentes a negócios muito voláteis.
Desenvolver software é um grande desafio, quem pensa que é das tarefas mais fáceis construir aplicações que realmente tenham sucesso e venham atender os usuários adequadamente, está redondamente enganado. O que nos fazem ter esta certeza são as variantes envolvidas no processo de desenvolvimento, mercados voláteis, negócios dinâmicos, requisitos que mudam, enfim todos estes fatores envolvidos tornam um desafio construir aplicações que sejam aderentes a estes itens citados, e que tenham condições de sobreviver mediante estas dificuldades.
Atualmente a indústria de software vem travando uma intensa batalha contra o negativo índice existente, quando falamos de projetos de sucesso; o Chaos Report aponta que somente 32% dos projetos de software obtêm sucesso e incríveis 68% são de fracasso. Isto se dá, por que na maioria das vezes, valorosas técnicas como: patterns de arquitetura, patterns de projeto, boas práticas, ferramentas adequadas, processos mais iterativos e incrementais, como o agile por exemplo, são ignorados ou até mesmo rejeitados no processo de desenvolvimento da aplicação. Ignora-se que para que a aplicação possa suportar as mudanças que certamente irá sofrer, precisa ser concebida sob os pilares sólidos, que são as ferramentas citadas, resultando assim em aplicações mal planejadas, que não atendem ao cliente, e que são classificadas como “monolíticas”, ou para ser mais exato, verdadeiros “monstros monolíticos”.
A natureza das aplicações monolíticas
Uma aplicação é classificada como monolítica quando os componentes de software que a compõem são extremamente acoplados, não há uma clara separação entre eles, não há separação de preocupações (Separation of Concerns), não há separação de responsabilidades e, além disso, são extremamente difíceis de serem mantidas, alteradas e a substituição de componentes que não serão mais utilizados, é ainda mais custosa. As aplicações monolíticas têm sua origem na falta de princípios fundamentais como empregar as boas práticas de desenvolvimento e testes unitários. Um desses princípios é o chamado Aberto/Fechado. Este princípio nos diz que uma entidade de software deve ser aberta para extensão, mas fechada para modificação.
Em grandes empresas existem sistemas que são gigantescos, controlam boa parte do negócio da mesma, e é extremamente custoso manter este “monstro Monolítico”, mas por ter tido um crescimento, mesmo sem estar devidamente fundamentado, torna-se quase que inviável sua substituição (custo altíssimo para fazer outro do zero) então se gasta rios de dinheiro para dar manutenção.
Nota do DevMan
Separação de Preocupações ou Separation Of Concerns é um princípio de engenharia de software que nos diz que temos que ter uma clara separação de preocupação por parte dos componentes de software. Não podemos ter, por exemplo, um componente de banco de dados que ao mesmo tempo realize o log, caso algum erro aconteça. O ideal seguindo o SoC, é que uma vez o componente de banco de dados tenha a necessidade de logar uma exceção, delegue esta tarefa a quem tem esta “preocupação” ou função no caso um componente de log.
Nota do DevMan
O princípio do Aberto/Fechado é um dos princípios SOLID. Os princípios SOLID foram introduzidos por Robert C. Martin, ou, como é comumente chamado “Uncle Bob”. Ele nos diz que uma entidade de software precisa estar fechada para modificação, mas aberta para extensão. Isto combate um problema comum que acontece em que ao alterarmos uma funcionalidade, acaba-se criando problema em outras partes do sistema. É muito comum de acontecer em aplicações monolíticas.
" [...] continue lendo...
