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
Reflection com Banco de Dados - Artigo .net Magazine 85
O artigo começa a expor as ferramentas existentes no framework .NET para a implementação das técnicas de Reflection que na programação cuidam de descobrir dados sobre classes e métodos de outros programas e bibliotecas.
.net Magazine 85
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 85
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 85
Reflection com Banco de Dados
Como usar os recursos de Reflection para preencher dados de classes
Descobrindo a estrutura dos objetos
Com o surgimento da programação orientada a objetos muitas tarefas repetitivas diminuíram porque conceitos como reutilização, polimorfismo e encapsulamento começaram a fazer parte do vocabulário e das ferramentas que o programador tem acesso. No centro estão as classes que servem de modelos para objetos lógicos em torno dos quais os programas são desenvolvidos.
Seus campos, propriedades, métodos, construtores e parâmetros provêm todos os recursos para o desenvolvimento das funcionalidades contidas em um programa. O caminho natural para o desenvolvimento de software é que com o tempo, bibliotecas criadas anteriormente tornem-se mais reaproveitadas por já resolverem um determinado problema evitando o retrabalho.
Tudo o que o programador precisa é conhecer a estrutura interna destas bibliotecas: suas classes e componentes e passar a usá-las conforme indicado na sua documentação. Ops! Que documentação? Como fazer para utilizar estas bibliotecas quando não há documentação? E mais: é possível descobrir dados de uma classe durante o tempo de execução de um programa?
Neste ponto surge uma dúvida: por que seria interessante descobrir dados de um objeto durante o runtime da aplicação e não fazer isto no projeto prevendo todas as situações possíveis?
Porque assim o software ficaria bastante limitado. Em muitas situações isto é o melhor a fazer, mas, se a necessidade for criar um programa mais flexível e adaptável, onde novas funcionalidades podem ser acrescentadas com um mínimo esforço, a possibilidade de o código conhecer a estrutura interna dos objetos é importante e auxilia nesta tarefa. São estes tipos de informação – os dados internos dos objetos – que podem ser chamados de metadados.
Reflection
Reflection é o processo que permite ler os metadados de um programa que pode ser o que está sendo executado ou outro programa ou class library. Também permite inspecionar arquivos executáveis portáveis (arquivos executáveis e class library do framework .NET, também chamados de assembly ou pela sigla PE de Portable Executable) e preencher componentes de tipos e seus membros em tempo de execução.
O framework .NET define tipos que permitem analisar os metadados dos assemblys. Os que compõem System.Reflection são:
• Assembly;
• Module;
• ParameterInfo;
• MemberInfo;
• MethodInfo;
• ConstructorInfo;
• FieldInfo;
• EventInfo;
• PropertyInfo.
Os próximos estão em System.Type:
• Enum;
• Type.
A principal classe a ser usada nas tarefas de reflection é System.Type. É com ela que se descobre o nome tipo do dado, quais tipos estão presentes em um módulo (um assembly pode conter um ou vários módulos), se determinado tipo de dado é por valor ou referência. Também permite descobrir os métodos, propriedades e campos e eventos. As tarefas de serialização de dados usam reflection.
Nota do DevMan
Por serialização entende-se como o processo onde um objeto é convertido em um array de bytes para que possa ser armazenado ou transmitido por qualquer meio que seja. Para que isto seja possível, os dados serializados precisam guardar também informações sobre sua estrutura para que o objeto possa ser reconstruído ao ser recuperado ou chegar ao seu destino. Os dois principais tipos de serialização são a binária e a XML onde um objeto é convertido para o formato XML usando sua estrutura de TAGS.
Através de reflection pode-se usar uma técnica de programação chamada de late binding. Esta técnica consiste em só carregar os módulos de um assembly a partir de parâmetros que só serão conhecidos em tempo de execução da aplicação, ou seja, ao criar o projeto não se conhece qual assembly (um módulo de uma dll por exemplo) deverá ser usado para executar determinada tarefa, então, para isto, os métodos contidos em System.Reflection.Assembly: Load, LoadFrom e LoadWithPartialName permitem este tipo de tarefa.
Antes de começar a trabalhar com reflection é importante conhecer um pouco sobre os assemblys e metadados dos arquivos executáveis do framework .NET.
Assembly e Metadata
Assembly: arquivo do tipo DLL ou EXE;
Manifest: descrição detalhada (metadados) de um assembly.
Um arquivo .exe ou .dll do framework .NET é principalmente formado por metadados e IL (Intermediate Language - a linguagem intermediaria entre o framework e o código nativo da máquina, somente interpretada pelo framework – Veja nota do DevMan).
Assim, um executável do .NET pode facilmente ser lido por outro, através do uso de reflection e ter os seus membros examinados e conhecidos durante o runtime. Os metadados contêm basicamente tabelas: de métodos, campos, propriedades, tipos, etc. É através destas tabelas que o System.Reflection pode obter dados sobre o assembly.
Nota: Quando se instala o Visual Studio 2010 uma ferramenta para visualização dos metadados é instalada junto. Esta ferramenta chamada de IL Disassembler permite abrir um assembly e inspecionar o seu conteúdo detalhadamente exibindo inclusive o código IL que foi gerado para o arquivo.
Ao ler os metadados todas as informações podem ser obtidas: nomes de propriedades, campos, métodos, construtores, atributos, tipos dos dados de cada um destes elementos, parâmetros que devem ser enviados para os métodos e construtores.
Também é possível descobrir os elementos pelo seu modo de acesso obtendo informações somente de elementos que são públicos, privados, de instância ou estáticos (static). Esta maneira como o .NET armazena os nomes dos elementos de um assembly é bastante útil para as tarefas relacionadas com reflection, mas, possuem a desvantagem de deixarem expostos os elementos. Podem existir casos em que isto não seja desejável para, por exemplo, proteger a propriedade intelectual de uma determinada empresa, ou, evitar cópias do código, muito embora, mesmo sendo possível escrever um programa usando IL, não é muito prático.
Para proteger um pouco mais o conteúdo do assembly é possível usar uma ferramenta que embaralha os nomes dos parâmetros usados no código, entre outras tarefas, o que dificulta um pouco a sua cópia. Mesmo que não seja grande coisa, já é uma forma a mais – existem outros utilitários para embaralhar o conteúdo do IL – de proteger o código que é gerado.
Nota do DevMan
IL
A IL – Intermediate Language (também conhecida como Common Intermediate Language (CIL), ou ainda Microsoft Intermediate Language (MSIL)) é conceito central do .NET Framework. Independente da linguagem de programação que você utilize, quando compila, seu código-fonte é convertido para IL. Entendendo IL você conseguirá: Entender melhor como o código gerenciado que você escreve realmente funciona; Examinar o código gerado pelo compilador (independente da linguagem); Escrever algum código diretamente em IL.
Em sua forma mais comum, Intermediate Language é uma linguagem binária. Como ocorre com a linguagem assembly nativa, uma instrução IL é armazenada em um container assembly (geralmente arquivos .exe ou .dll) em uma representação numérica binária.
Entretanto, como também ocorre com um código executável nativo, uma linguagem textual foi definida para representar a IL. Essa linguagem é constituída por códigos mnemônicos que, por sua vez, representam os comandos IL binários. Essa linguagem é conhecida como IL assembly. Entretanto, como IL Assembly é um nome muito longo, existe uma convenção em encurtar esse nome para ILAsm ou, simplesmente, código-fonte IL.
Todo arquivo executável (EXE) ou biblioteca (DLL) que seu compilador gera para você contém um código executável. Em .NET, esse código está escrito em uma especificação conhecida como Intermediate Language, que é binária. Além disso, existe uma forma textual de representar esse conteúdo executável.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Como usar os recursos de Reflection para preencher dados de classes
Descobrindo a estrutura dos objetos
Com o surgimento da programação orientada a objetos muitas tarefas repetitivas diminuíram porque conceitos como reutilização, polimorfismo e encapsulamento começaram a fazer parte do vocabulário e das ferramentas que o programador tem acesso. No centro estão as classes que servem de modelos para objetos lógicos em torno dos quais os programas são desenvolvidos.
Seus campos, propriedades, métodos, construtores e parâmetros provêm todos os recursos para o desenvolvimento das funcionalidades contidas em um programa. O caminho natural para o desenvolvimento de software é que com o tempo, bibliotecas criadas anteriormente tornem-se mais reaproveitadas por já resolverem um determinado problema evitando o retrabalho.
Tudo o que o programador precisa é conhecer a estrutura interna destas bibliotecas: suas classes e componentes e passar a usá-las conforme indicado na sua documentação. Ops! Que documentação? Como fazer para utilizar estas bibliotecas quando não há documentação? E mais: é possível descobrir dados de uma classe durante o tempo de execução de um programa?
Neste ponto surge uma dúvida: por que seria interessante descobrir dados de um objeto durante o runtime da aplicação e não fazer isto no projeto prevendo todas as situações possíveis?
Porque assim o software ficaria bastante limitado. Em muitas situações isto é o melhor a fazer, mas, se a necessidade for criar um programa mais flexível e adaptável, onde novas funcionalidades podem ser acrescentadas com um mínimo esforço, a possibilidade de o código conhecer a estrutura interna dos objetos é importante e auxilia nesta tarefa. São estes tipos de informação – os dados internos dos objetos – que podem ser chamados de metadados.
Reflection
Reflection é o processo que permite ler os metadados de um programa que pode ser o que está sendo executado ou outro programa ou class library. Também permite inspecionar arquivos executáveis portáveis (arquivos executáveis e class library do framework .NET, também chamados de assembly ou pela sigla PE de Portable Executable) e preencher componentes de tipos e seus membros em tempo de execução.
O framework .NET define tipos que permitem analisar os metadados dos assemblys. Os que compõem System.Reflection são:
• Assembly;
• Module;
• ParameterInfo;
• MemberInfo;
• MethodInfo;
• ConstructorInfo;
• FieldInfo;
• EventInfo;
• PropertyInfo.
Os próximos estão em System.Type:
• Enum;
• Type.
A principal classe a ser usada nas tarefas de reflection é System.Type. É com ela que se descobre o nome tipo do dado, quais tipos estão presentes em um módulo (um assembly pode conter um ou vários módulos), se determinado tipo de dado é por valor ou referência. Também permite descobrir os métodos, propriedades e campos e eventos. As tarefas de serialização de dados usam reflection.
Nota do DevMan
Por serialização entende-se como o processo onde um objeto é convertido em um array de bytes para que possa ser armazenado ou transmitido por qualquer meio que seja. Para que isto seja possível, os dados serializados precisam guardar também informações sobre sua estrutura para que o objeto possa ser reconstruído ao ser recuperado ou chegar ao seu destino. Os dois principais tipos de serialização são a binária e a XML onde um objeto é convertido para o formato XML usando sua estrutura de TAGS.
Através de reflection pode-se usar uma técnica de programação chamada de late binding. Esta técnica consiste em só carregar os módulos de um assembly a partir de parâmetros que só serão conhecidos em tempo de execução da aplicação, ou seja, ao criar o projeto não se conhece qual assembly (um módulo de uma dll por exemplo) deverá ser usado para executar determinada tarefa, então, para isto, os métodos contidos em System.Reflection.Assembly: Load, LoadFrom e LoadWithPartialName permitem este tipo de tarefa.
Antes de começar a trabalhar com reflection é importante conhecer um pouco sobre os assemblys e metadados dos arquivos executáveis do framework .NET.
Assembly e Metadata
Assembly: arquivo do tipo DLL ou EXE;
Manifest: descrição detalhada (metadados) de um assembly.
Um arquivo .exe ou .dll do framework .NET é principalmente formado por metadados e IL (Intermediate Language - a linguagem intermediaria entre o framework e o código nativo da máquina, somente interpretada pelo framework – Veja nota do DevMan).
Assim, um executável do .NET pode facilmente ser lido por outro, através do uso de reflection e ter os seus membros examinados e conhecidos durante o runtime. Os metadados contêm basicamente tabelas: de métodos, campos, propriedades, tipos, etc. É através destas tabelas que o System.Reflection pode obter dados sobre o assembly.
Nota: Quando se instala o Visual Studio 2010 uma ferramenta para visualização dos metadados é instalada junto. Esta ferramenta chamada de IL Disassembler permite abrir um assembly e inspecionar o seu conteúdo detalhadamente exibindo inclusive o código IL que foi gerado para o arquivo.
Ao ler os metadados todas as informações podem ser obtidas: nomes de propriedades, campos, métodos, construtores, atributos, tipos dos dados de cada um destes elementos, parâmetros que devem ser enviados para os métodos e construtores.
Também é possível descobrir os elementos pelo seu modo de acesso obtendo informações somente de elementos que são públicos, privados, de instância ou estáticos (static). Esta maneira como o .NET armazena os nomes dos elementos de um assembly é bastante útil para as tarefas relacionadas com reflection, mas, possuem a desvantagem de deixarem expostos os elementos. Podem existir casos em que isto não seja desejável para, por exemplo, proteger a propriedade intelectual de uma determinada empresa, ou, evitar cópias do código, muito embora, mesmo sendo possível escrever um programa usando IL, não é muito prático.
Para proteger um pouco mais o conteúdo do assembly é possível usar uma ferramenta que embaralha os nomes dos parâmetros usados no código, entre outras tarefas, o que dificulta um pouco a sua cópia. Mesmo que não seja grande coisa, já é uma forma a mais – existem outros utilitários para embaralhar o conteúdo do IL – de proteger o código que é gerado.
Nota do DevMan
IL
A IL – Intermediate Language (também conhecida como Common Intermediate Language (CIL), ou ainda Microsoft Intermediate Language (MSIL)) é conceito central do .NET Framework. Independente da linguagem de programação que você utilize, quando compila, seu código-fonte é convertido para IL. Entendendo IL você conseguirá: Entender melhor como o código gerenciado que você escreve realmente funciona; Examinar o código gerado pelo compilador (independente da linguagem); Escrever algum código diretamente em IL.
Em sua forma mais comum, Intermediate Language é uma linguagem binária. Como ocorre com a linguagem assembly nativa, uma instrução IL é armazenada em um container assembly (geralmente arquivos .exe ou .dll) em uma representação numérica binária.
Entretanto, como também ocorre com um código executável nativo, uma linguagem textual foi definida para representar a IL. Essa linguagem é constituída por códigos mnemônicos que, por sua vez, representam os comandos IL binários. Essa linguagem é conhecida como IL assembly. Entretanto, como IL Assembly é um nome muito longo, existe uma convenção em encurtar esse nome para ILAsm ou, simplesmente, código-fonte IL.
Todo arquivo executável (EXE) ou biblioteca (DLL) que seu compilador gera para você contém um código executável. Em .NET, esse código está escrito em uma especificação conhecida como Intermediate Language, que é binária. Além disso, existe uma forma textual de representar esse conteúdo executável.
"
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
Vladimir Rech
Space do autor
Tecnólogo em Desenvolvimento de Sistemas pelo CEFET-PR, palestrante; trabalha com desenvolvimento de sistemas em .NET destacando-se aplicações Windows, ASP e Web Services.
Space do autor
0
0
