Um entendimento aprofundado sobre o Microsoft Extensbility Framework, ou simplesmente MEF, sua arquitetura e conceitos. Através de exemplos práticos serão ilustradas formas de aplicar o framework para extensibilidade de aplicações.
Em que situação o tema é útil
Como ferramenta de auxílio na criação de aplicações extensíveis, dinâmicas. No desenvolvimento de sistemas que queiram oferecer pontos de extensão e não somente em cenários como este, mas também na criação de frameworks.
MEF
Ao chegar ao mercado o MEF causou um grande impacto. Normal para uma tecnologia nova que está sendo introduzida. Mas o grande atrativo do MEF foi permitir a extensibilidade de aplicações. Veio trazer uma nova maneira de se estender aplicações, como também, uma motivação maior de construir este tipo de aplicação. Sabemos que o processo de desenvolvimento de software envolve prazo, custo, manutenção e etc. De acordo com a complexidade envolvida, torná-la extensível pode dar mais trabalho. Com o surgimento do MEF nasceu na comunidade uma opção de fazer este tipo de aplicação, de maneira mais suave e simples, porque o MEF é simples de usar.
O MEF é um framework que nasceu com o objetivo de ser uma poderosa ferramenta para criação e gerenciamento de extensibilidade em aplicações, ou seja, que as aplicações tenham sua arquitetura utilizando o conceito de extensibilidade e baseada em plugins. A busca por este tipo de aplicação está relacionada a problemas comuns que são encontrados no ciclo de desenvolvimento de uma aplicação, e no processo que sucede este ciclo, que é a fase de manter a aplicação, tornando-a mais aderente à mudanças e também fazer com que tarefas como adicionar novas funcionalidades, seja suave ou menos custosa.
Gerenciar extensibilidade até então não era uma das tarefas mais fáceis, embora antes do MEF nascer já existisse o System.AddIn. Não existia um framework que fosse mais simples de usar como o MEF. O MEF veio para atender a um constante desafio de quem deseja ter aplicações que pudessem ser estendidas em tempo de runtime, ou seja, aplicações que mesmo após distribuição, pudessem até mesmo ter sua interface alterada, ou até mesmo estendida através de componentes de terceiros que respeitassem um determinado contrato que fosse estabelecido.
Abstrações, um dos fundamentos da extensibilidade
Um princípio de orientação a objetos muito importante e não tão explorado quanto deveria, é a abstração. Abstrair conceitos, regras de negócio, é algo que é comum no mundo do desenvolvimento orientado a objetos. A grande questão é que não devemos abstrair somente buscando traduzir em objetos conceitos do mundo real, mais utilizar também abstração como uma espécie de “camada de contratos de comunicação”, ou seja, interfaces que devem ser respeitadas para que se estabeleça uma ligação entre quem deseja “respeitar” este contrato, e quem “disponibiliza” o contrato.
Quando começamos a trabalhar em um nível abstrato, não temos mais a responsabilidade de saber quais classes concretas respeitam o contrato exposto. Uma vez que um contrato é disponibilizado por meio de uma interface, o que interessa para a aplicação host é única e exclusivamente obter uma instância de alguém que respeita o contrato em questão. Um exemplo claro é a questão de acesso a banco de dados. Quando há a necessidade de uma aplicação multibancos, pode-se disponibilizar um contrato para que de acordo com o banco de dados em questão, exista uma classe que realize efetivamente as operações com o mesmo, bastando para isto que a classe concreta respeite o contrato em questão.
Os design patterns, são ferramentas essenciais para se obter extensibilidade em aplicações ou frameworks. Muitos deles fazem fortemente uso do poder das abstrações. Na verdade, a abstração é mola mestra em alguns patterns como: Template Method, Strategy e em princípios de boas práticas, como o do Aberto/Fechado.
Os padrões de projeto (design patterns) assim como os princípios SOLID fazem parte de um conjunto de boas práticas que podem/devem ser seguidas por qualquer desenvolvedor que deseja utilizar a orientação a objetos de forma séria. Os padrões de projeto dizem respeito a soluções para problemas recorrentes. São soluções para problemas que aconteceram, acontecem e continuam acontecendo durante o design de um software. Esses padrões mostram como solucionar tais dificuldades mantendo boas práticas como baixo acoplamento e alta coesão. Os princípios SOLID são compostos por boas práticas, que formam seu nome: Single Responsability Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP) e Dependency Inversion Principle.
Extensibilidade e os
HotSpots ...
