|
Framework .NET |
Conceitos
A plataforma .NET é uma Framework para desenvolvimento de aplicações distribuidas e colaborativas entre linguagens, podendo também ser multiplataforma. Utiliza o Visual Studio.NET (VS.NET) como base do ambiente de desenvolvimento.
Recursos disponíveis
ü IDE: todas as linguagens compartilham o mesmo IDE do VS.NET, mecanismo de formulário, mecanismo de tratamento de exceções etc. Isso significa que o IDE das linguagens .NET (como o Powercobol.NET, o NetExpress.NET, o VB.NET e a C#) será muito semelhante ao do Visual Studio.
ü CLR: o CLR é o runtime do VS.NET, sendo responsável pela maioria dos recursos-chave de qualquer linguagem da plataforma .NET. Ele responde pela implementação, herança de linguagens e free-threading. No VS.NET todas as linguagens compartilham o mesmo runtime, o CLR.
ü IL: o código de uma linguagem .NET é compilado em uma linguagem IL (Intermediate Language), independentemente de você escrever um aplicativo em Cobol, VB, C# ou qualquer outra linguagem. Quando o aplicativo é executado, um compilador JITer (just-in-time) converte o código IL em linguagem de máquina. Da mesma forma como acontece com o Cobol Micro Focus que gera código .INT portável entre plataformas, teoricamente será possível criar runtimes de .NET para plataformas não Windows (já existem iniciativas para portar o .NET para FreeBSD e Linux).
ü Integração: o CLR oferece integração entre as linguagens, permitindo inclusive que estas herdem códigos entre si. Como todas as linguagens utilizam o CLR, significa que compartilham um tipo comum de sistema, o que facilita o desenvolvimento de aplicativos que fazem uso de várias linguagens.
ü Gerenciamento de Memória: o código executado no CLR é chamado de código gerenciado, pois o CLR controla toda a memória, trazendo muitas vantagens, como integração entre linguagens, tratamento de exceção entre linguagens, além de um modelo simplificado para interação de componentes. A exceção é a linguagem C#, que é capaz de alternar para um código não-gerenciado (fora do runtime) e desempenhar funções como manipulação de ponteiro.
ü Liberação de Memória: tudo no .NET é objeto, inclusive as seqüências de caracteres. Por esse motivo (e muitos outros), a Microsoft mudou a forma como a arquitetura trata os objetos carregados, passando a usar o conceito Garbage Colection para liberação de memória no lugar do antigo esquema de Contagem de Referência utilizado na arquitetura COM.
ü XML: o XML está por trás de tudo no VS.NET, de arquivos de configuração a chamadas de procedimento local e remotas. O .NET explora os recursos XML em três áreas-chave: configuração e metadados, acesso a dados e acessos remotos (remoting).
ü WinForms: a Microsoft substituiu o antigo mecanismo de formulários por WinForms. Agora você terá um conjunto rico de ferramentas de UI, mas precisará melhorar suas habilidades atuais de criação de formulários.
ü WebForms: o .NET oferece um mecanismo de formulário projetado especialmente para criar formulários Web, porém semelhante ao mecanismo de criação de formulários para aplicativos desktop Windows. Os WebForms trabalham em conjunto com o ASP.NET, sendo que a framework captura os dados do evento no cliente e os envia para o servidor. Isto significa que a interface de seu aplicativo dependerá do navegador. Você poderá, por exemplo, aproveitar as vantagens dos recursos específicos ao Internet Explorer se puder abrir mão da independência do navegador. Os Web Forms facilitarão a criação de eventos de UI mais ricos e modernos para aplicativos orientados a Web.
ü WebServices: a equipe de marketing da Microsoft tem citado os serviços Web como uma das maiores razões para se adotar o .NET. Em sua essência, os WebServices são objetos semelhantes ao COM expostos através de um servidor Web e que utilizam protocolos baseados em padrões. Os WebServices são disponibilizados aos programadores através de listas suspensas (drop-down) com tecnologia intellisense.
ü ADO.NET: o Visual Studio.NET é fornecido com o ADO.NET, uma versão moderna do ADO (ActiveX Data Objects) que oferece vários benefícios, principalmente porque o ADO.NET usa o XML como o formato de transmissão de dados entre os componentes.
ü Empacotamento e Distribuição de Aplicativos: um dos pontos mais fortes do .NET é a forma de empacotamento e distribuição dos aplicativos como Assemblies, eliminando os terríveis conflitos de DLLs. Como os Assemblies são autodescritivos (através de seu manifesto), os aplicativos .NET não precisarão modificar o Registry para funcionar, ou seja, não será mais necessário registrar componentes.
Alguns conceitos
ü Coletor de Lixo (Garbage Collection): Basicamente, o coletor de lixo monitora os recursos de um programa, procurando objetos não usados quando os recursos disponíveis atingem um dado limiar e destrói esses objetos à medida que os encontra. Uma grande vantagem da coleta de lixo é não precisar mais se preocupar com os tipos mais comuns de referências circulares, nas quais um objeto-filho faz referência a um objeto-pai e vice-versa. No esquema de contagem de referência, as referências circulares impedem que os objetos sejam liberados e destruídos. No sistema com coleta de lixo, o coletor de lixo encontra essas referências circulares e as destrói. Isso significa também que a liberação da última referência a um objeto nem sempre destruirá imediatamente o objeto.
ü Contagem de Referência: esquema utilizado na arquitetura COM (ActiveX) no qual sempre que é feita uma referência a um objeto, um contador é decrementado quando a referência a um objeto está fora do escopo ou é liberada, e o objeto é terminado quando o contador é zerado. A Microsoft afirma que a sobrecarga resultante da contagem de referência no .NET. Framework revelou-se muito alta para justificar sua implementação no programa. Em vez disso, abriu mão desse recurso em favor da coleta de lixo.
ü Assemblies: os Assemblies agrupam o conjunto de objetos e informações do aplicativo. Possuem metadados, que descrevem tudo que o assembly precisa executar. Os metadados, chamados de manifesto, contém informações como a identidade do assembly (nome, versão etc) e uma tabela de arquivos que lista todas as dependências do arquivo, bem como suas localizações e versões. Além disso, contêm informações sobre dependência externa com dados a respeito de DLLs e outros recursos nos quais o assembly se baseie, mas que não tenham sido criados pelo desenvolvedor. Como os Assemblies são autodescritivos (através de seu manifesto), os aplicativos .NET não precisarão modificar o Registry para funcionar, ou seja, não será mais necessário registrar componentes. Na melhor das hipóteses se existir um run-time .NET em uma máquina cliente, a distribuição de um aplicativo complexo exigirá apenas cópia de uma pasta para uma máquina de destino. Outra vantagem dos assemblies é o fato de que permitem ter diferentes aplicativos com diferentes versões da mesma DLL, todos funcionando de forma harmoniosa em uma máquina. Se esses novos recursos funcionarem como esperado, os problemas com DLLs e os pesadelos com as versões serão lembranças do passado.
ü ADO.NET: o ADO.NET é uma tecnologia de última geração de acesso a dados da Microsoft e oferece vantagens significativas em relação a sua predecessora. O ADO.NET usa o XML como o formato de transmissão de dados entre os componentes. Isso significa que o componente receptor não precisa ser um componente ADO.NET, desde que possa receber conjuntos de dados formatados em XML. O ADO.NET também proporciona um desempenho melhor do que o ADO quando se trata de trabalhar com datasets desconectados, bem como maior escalabilidade.Algumas desvantagens do .NET
ü Performance: o conceito da compilação gerando linguagem IL com o JITer carregando a aplicação é muito semelhante à compilação Cobol gerando código intermediário .INT sendo carregado pelo runtime. Já temos experiência de que o código .INT é mais lento que um .EXE
ü Compilação reversa: a IL é susceptível à compilação reversa. Essa possibilidade tem gerado muitas dúvidas em relação à segurança geral da Framework .NET.
ü Aplicativos Legados: a arquitetura subjacente do Visual Studio .NET não é COM. Fica a dúvida então em relação à compatibilidade com os componentes ActiveX já existentes, não .NET.
ü WebServices: apesar dos WebServices se comportarem como objetos .COM, eles não são tecnicamente a mesma coisa e trabalham com o ASP.NET. A Microsoft gostaria de ver todos os tipos de empresa hospedando WebServices, e os aplicativos do futuro deverão apenas "juntar" os vários WebServices, da mesma forma que se utiliza hoje o VBA (Visual Basic for Applications) para criar soluções para aplicativos Office e VBA. Os WebServices fazem parte de uma ambiciosa estratégia da Microsoft, mas só o tempo dirá se a empresa alcançou seu intuito de ver os WebServices utilizados em larga escala. Contudo, o conceito é promissor.