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.
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.
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.
O conceito de composição
Os fundamentos de uma aplicação de composição estão em se conceber um aplicativo que tenha componentes semi-independentes, fracamente acoplados que possam ser adicionados ou substituídos facilmente, mesmo durante a execução do sistema. Os componentes se integrem com uma parte central do sistema denominado “shell”, que é onde os componentes estarão integrados e organizados. As aplicações compostas são um dos remédios contra as aplicações monolíticas. Elas nos trazem inúmeros benefícios que fazem alcançarmos o objetivo de termos uma arquitetura flexível e robusta, que torna mais suave o processo de manutenção, evolução ou até mesmo, substituição de componentes e adição de novas funcionalidades.
Na arquitetura de um sistema que utiliza o conceito de composição e o Prism, os componentes são semi-independentes, isto quer dizer que eles podem ser desenvolvidos em separado, para posteriormente serem integrados no módulo principal denominado Shell, como dito anteriormente. Esta independência dos componentes, que dentro da arquitetura de composição são chamados de módulos, permite que os mesmos sejam testados e implementados individualmente, mais sem afetar os demais módulos que possam estar em desenvolvimento paralelo por outros desenvolvedores, e até mesmo, outra equipe.
...
