Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
MEF – Parte 1 - .net magazine 73
Este artigo vai discutir a criação de programas que podem ser estendidos e mantidos mais facilmente, quer seja por você, por sua equipe ou por terceiros. Aproveitando o tema, falarei sobre programas que suportam plugins e darei um exemplo de mecanismo feito “como antigamente”, que servirá como ponto de partida para a apresentação do MEF (Managed Extensibility Framework).
.net Magazine 73
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 73
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 73
MEF – Parte 1
Design de programas fechados para manutenção mas abertos para extensão
Resumo do DevMan
O MEF (Managed Extensibility Framework) é um novo recurso do .NET Framework 4 para criação de programas que podem ser estendidos dinamicamente (plugins no jargão de desenvolvimento de programas). Nesta primeira parte do artigo será abordada a criação de programas fáceis de manter e estender, segundo alguns conhecidos princípios de designs que serão úteis inclusive para o entendimento da arquitetura do MEF. Além disto, um mecanismo de plugins “old school” será criado para poder servir de comparação na parte 2 deste artigo, que mostrará uma implementação muito melhor feita com o auxílio do MEF.
Enquanto pensava sobre como falar do MEF, que é um framework para facilitar a criação de programas que suportam extensão por plugins, peguei-me analisando o quanto de design há neste framework propriamente dito e como a discussão sobre design tem perdido espaço para frameworks cada vez mais especializados e metodologias cada vez mais voltadas ao código. O que eu quero dizer é que a quantidade de material e discussão sobre design é relativamente pequena quando comparada a outros tipos de informações.
Nessa linha de pensamento, pensei o seguinte: criar programas que suportem plugins, com ou sem o MEF, é uma ótima maneira de se conversar sobre design. Pela própria natureza do problema somos levados a criar código menos acoplado, impelidos a programar para interface, ao invés de tipos concretos e quase naturalmente obrigados a encapsular aquilo que pode ser alterado.
Estes três princípios de design serão muito úteis para entendimento e utilização do MEF, mas são também princípios básicos para ajudar qualquer desenvolvedor a criar programas mais fáceis de manter e alterar, quer eles suportem plugins ou não.
Apenas para ilustrar o que estou dizendo, vou relatar um exemplo real. Durante uma manutenção em uma classe para impressão de notas fiscais me deparei com uma estrutura muito interessante que continha as seguintes classes:
• ModelFiscalNote: Classe principal do modelo para nota fiscal (havia outras abaixo dela, mas para este relato ela basta);
• ModelPrintDocument: Classe para definição de um documento a ser impresso. Contém propriedades para tamanho do formulário e contém também uma lista de elementos para impressão;
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Design de programas fechados para manutenção mas abertos para extensão
Resumo do DevMan
O MEF (Managed Extensibility Framework) é um novo recurso do .NET Framework 4 para criação de programas que podem ser estendidos dinamicamente (plugins no jargão de desenvolvimento de programas). Nesta primeira parte do artigo será abordada a criação de programas fáceis de manter e estender, segundo alguns conhecidos princípios de designs que serão úteis inclusive para o entendimento da arquitetura do MEF. Além disto, um mecanismo de plugins “old school” será criado para poder servir de comparação na parte 2 deste artigo, que mostrará uma implementação muito melhor feita com o auxílio do MEF.
Enquanto pensava sobre como falar do MEF, que é um framework para facilitar a criação de programas que suportam extensão por plugins, peguei-me analisando o quanto de design há neste framework propriamente dito e como a discussão sobre design tem perdido espaço para frameworks cada vez mais especializados e metodologias cada vez mais voltadas ao código. O que eu quero dizer é que a quantidade de material e discussão sobre design é relativamente pequena quando comparada a outros tipos de informações.
Nessa linha de pensamento, pensei o seguinte: criar programas que suportem plugins, com ou sem o MEF, é uma ótima maneira de se conversar sobre design. Pela própria natureza do problema somos levados a criar código menos acoplado, impelidos a programar para interface, ao invés de tipos concretos e quase naturalmente obrigados a encapsular aquilo que pode ser alterado.
Estes três princípios de design serão muito úteis para entendimento e utilização do MEF, mas são também princípios básicos para ajudar qualquer desenvolvedor a criar programas mais fáceis de manter e alterar, quer eles suportem plugins ou não.
Apenas para ilustrar o que estou dizendo, vou relatar um exemplo real. Durante uma manutenção em uma classe para impressão de notas fiscais me deparei com uma estrutura muito interessante que continha as seguintes classes:
• ModelFiscalNote: Classe principal do modelo para nota fiscal (havia outras abaixo dela, mas para este relato ela basta);
• ModelPrintDocument: Classe para definição de um documento a ser impresso. Contém propriedades para tamanho do formulário e contém também uma lista de elementos para impressão;
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Você está em:
canal .net
Publicidade
-2.jpg)
Marcelo Palladino
Space do autor
Marcelo Palladino (marcelopalladino@uol.com.br), trabalha profissionalmente com desenvolvimento à 16 anos. Neste período participou de projetos em empresas como Banco do Brasil, Embratel, Banco Safra, Rede Globo entre outras. Atualmente atua como desenvolvedor no grupo Sonda IT.
Space do autor
0
0
