Luz do sol eterna do .NET limpo

Quando comecei a trabalhar com o .NET Framework 3.5 (idioma versão 3.0) há 10 anos, para mim, sua funcionalidade era extremamente limitada, como comecei no SharePoint 2010. Estudando gradualmente uma gama mais ampla de tecnologias e seguindo o desenvolvimento do .NET, eu Percebo seu enorme crescimento, de um concorrente duvidoso para Java a uma plataforma cruzada interessante, com a capacidade de desenvolver daemons para Linux (e destinada exclusivamente ao Windows). Obviamente, quando me deparei com a tecnologia, parecia que tudo era suficiente: afinal, havia maneiras de implementar o que se pretendia. Mas agora, tendo experiência trabalhando em diferentes plataformas e suas diferentes versões, já podemos especular que a vida foi uma dor naqueles tempos distantes.

Em geral, se é interessante retornar mentalmente a essa época e refletir sobre o .NET juntos no contexto de "Era - Tornou-se", convido você a se interessar. Eu acho que será interessante para quem codifica recentemente e não conhece os recursos das versões anteriores e para quem quer se entregar à nostalgia.

Idade da Dor

Quando comecei a desenvolver, o SharePoint 2010 trabalhava no .NET Framework 3.5 e já incluía muito: o LINQ apareceu e havia o AJAX primitivo. Mas era muito limitado pela plataforma, pois era bastante difícil expandi-la e simplesmente não havia ferramentas adequadas na época.

Dor 1: Criando um Único Aplicativo

Em seguida, a tecnologia para o desenvolvimento de web parts para a "bola" foi baseada nos WebForms, sendo cada web essencialmente um aplicativo separado. Pessoalmente, não era realista para mim criar um único aplicativo dessa maneira, porque ao desenvolver a Web Part, cada um deles inicializa seu próprio contexto para conectar-se ao banco de dados - acontece que era impossível criar um único contexto. Bem, por exemplo, para exibir dados do banco de dados nas páginas, usei SqlDataSource (conectando-me ao banco de dados separadamente no widget) e, para conectar-se a 3-4 tabelas, eu tinha 3-4 DataSource no widget, o que, é claro, , influenciou a velocidade de carregamento da página. Naquela época, o ADO.NET Entity Framework já havia aparecido, mas era inconveniente usá-lo no SharePoint até a versão 4.1, porque houve problemas com a interação dos produtos.

Dor 2: Inacessibilidade de suporte e padrões

As Web parts para SP 2010 que escrevemos sobre a tecnologia de criação da Web Part SP 2007, porque não havia modelos ou suporte para o estúdio de 2008. Gradualmente, com o lançamento do Visual Studio 2010, seus modelos apareceram e ficou mais fácil trabalhar: tornou-se possível fazer definições de lista e codificá-las no estúdio, criar um modelo de site (codificar o tipo de conteúdo e a descrição da lista desejados). Anteriormente, tudo isso era feito manualmente através da edição de arquivos XML, e isso, sem dúvida, era uma dor para aqueles que estavam imersos no desenvolvimento .NET, porque a pessoa não entendia que tipo de arquivo estava corrigindo e com que finalidade, mas focava apenas em Palavras do tio do fórum.

Dor 3: assincronia ...

No .NET Framework 3.5, não havia assincronia ¬¬ no formato que o conhecemos agora, e tivemos que executar determinado código em outro thread, comunicar-se por meio de manipuladores delegados e, no WinForms, foi possível usar o plano de fundo de um trabalhador (ou seja, o segundo processo paralelamente em que o trabalho foi realizado). Acontece que a programação de aplicativos assíncronos existia, mas sua implementação foi além do entendimento de junho.

No .NET Framework 4, a Task Parallel Library apareceu e, portanto, as tarefas também apareceram, ou seja, não poderíamos declarar delegados, mas executar uma tarefa, passando uma ação a ela e executá-la em um encadeamento paralelo, conhecendo o status / estado e, quando necessário, receber um sinal sobre sua implementação. Foi um progresso para o desenvolvimento paralelo, quando você precisa processar uma grande quantidade de dados, porque antes isso era feito com uma barra de entrada maior.

... e janelas congeladas

Você precisa entender que a Web é muito diferente do desenvolvimento de aplicativos de console (aqui queremos dizer não nomeação global, mas aquela que usamos ao descrever as teses: não especificamente o ConsoleApp, mas todos os aplicativos executados na interface do SO). Em um aplicativo de console, todas as operações são executadas de forma síncrona por padrão e, se houver um longo tempo de processamento, a interface "congelará" como se o aplicativo estivesse congelado. Para não sentir que o programa não está respondendo, realizamos todas as operações em um encadeamento separado e inserimos barras de progresso: dessa forma, o usuário viu a atividade do aplicativo e foi possível controlar a partir de outro encadeamento por meio de um delegado, por exemplo.

Dor 4: a implantação está chegando

Também no .NET Framework 3.5, havia outra tecnologia dolorosa - o MS AJAX. O conteúdo UpdatePanel foi atualizado a partir do back-end, enquanto todo o resto não foi reconstruído. No SharePoint, ele trabalhou de maneira muito torta devido às especificidades da inicialização dos controles no ciclo de vida da página. Aqui, ele funcionou para nós após o primeiro post-back (às vezes após o segundo) e, em geral, era difícil fazer com que o MS AJAX funcionasse bem da primeira vez, embora tenha sido usado de maneira simples com o WebForm UpdatePannel limpo. E não foi possível usar o AJAX clássico (XMLHttpRequest) nessa versão da "bola", porque para cada ação era necessário escrever um manipulador separado nas costas e pendurá-los em um pacote de cada Web Part. Ao mesmo tempo, nem sempre era possível encerrar essa funcionalidade.

Quando, paralelamente, trabalhei com outros aplicativos escritos em WebForms para tarefas "quase bola", fiquei surpreso que o problema de implantar um projeto no SP seja um problema apenas para o SP. O restante dos aplicativos foram inicializados no momento: a janela foi carregada e funciona (mágica!). No balão, a implantação levou de 2 a 3 minutos e você está em um ciclo constante:



Em geral, todos entendiam que era um longo processo de implantação e mini-breaks. Mas sou grato por essa dor - então aprendi a gerar mais código e a cometer menos erros em uma iteração do desenvolvimento.

Dor 5: Windows e nada além de Windows

Naquela época, o .NET ainda se posicionava como uma plataforma de desenvolvimento para Windows. Sim, havia um projeto Mono, que, em essência, era uma “bicicleta” do .NET no Linux, mas era uma versão alternativa do Framework principal e ainda estava na página do projeto www.mono-project.com/docs/ sobre mono / compatibilidade ) lista os recursos que não são adicionados a ele pela versão do Framework. Quando você desenvolveu algo para o Linux, ficou longe de ser fácil de usar, já que o Mono não tinha esse suporte e comunidade e, se você recorresse a algumas coisas não realizadas, o código poderia simplesmente quebrar. Ou seja, se você não o desenvolver inicialmente para o Mono, não poderá escrever código independente de plataforma em princípio. Não excluo a importância deste projeto para o desenvolvimento do .NET como um todo, porque sem ele o Core não teria aparecido, mas, pessoalmente, não tive nenhuma experiência de combate com ele.

Age of Pros (Analgésico)

O próprio uso da versão mais recente do .NET pura em seus projetos elimina quase todos esses problemas. Existem muitas vantagens no Framework agora, mas falaremos sobre as vantagens de vincular ao Core, como Eu trabalhei com ele.

Plus 1: Desempenho

Quando o .NET Core apareceu, tornou-se possível realizar operações familiares muito mais legais e rápidas. Os aplicativos finais nele funcionam de acordo com alguns dados até 5.000 vezes mais rápidos que seus equivalentes no .NET Framework. Mas a compilação e o lançamento às vezes levam mais tempo - "arnês por um longo tempo - conduzam rápido".

Plus 2: plataforma cruzada

A principal vantagem do .NET Core é o fato de o código escrito funcionar simultaneamente no Windows, Linux e Mac. Nesse caso, você pode gravar um aplicativo na arquitetura de microsserviço do serviço de log assíncrono através da fila de mensagens. Lembro-me de como eu, um desenvolvedor que escreve principalmente no Windows, escrevi demônios (serviços) no Linux, e eles trabalharam de maneira estável, rápida e na primeira vez, e todo o sistema trabalhou em conjunto: no aplicativo, no serviço de API e na própria fila de mensagens. É apenas espaço, quando você escreve em seu idioma usual em uma plataforma que não foi originalmente projetada para este sistema operacional!

Plus 3: Assíncrono de tudo

Agora é possível gravar o backup não em paralelo, sem multithread, mas completamente de forma assíncrona (!), O que permite remover tarefas individuais do fluxo principal em métodos assíncronos especiais ou blocos de código. Isso, por sua vez, permite que você escreva um código bonito e limpo, sem construções volumosas: é fácil de entender, os métodos assíncronos são escritos como síncronos e funcionam como deveriam.

Plus 4: descarregando bibliotecas e consumo de memória menos intensivo

Se você olhar para a 8ª versão atual do C #, ela tem muito açúcar e as mudanças são fascinantes. Primeiro, antes não tínhamos a capacidade de descarregar dinamicamente a DLL inicialmente descarregada (carregamos dinamicamente as bibliotecas no projeto, mas elas permaneceram travadas na memória). Com o lançamento do 3rd Core, tornou-se possível carregar e descarregar dinamicamente bibliotecas, dependendo dos objetivos. Por exemplo, se queremos criar um aplicativo de pesquisa de arquivos e o usuário seleciona a extensão XML, carregamos dinamicamente o analisador XML de documentos e pesquisamos em sua árvore. Se queremos pesquisar pelo JSON, começamos a pesquisar pelo seu corpo - bibliotecas que dependem de certas condições e não há necessidade de mantê-las na RAM. E sim O aplicativo parou de consumir memória constantemente. Quando descarregamos a montagem, liberamos todos os recursos que se apegam a essa montagem.

Plus 5: tuplas

A linguagem ainda é jovem, vibrante e ativamente em desenvolvimento. A versão mais recente adicionou muitas coisas interessantes: por exemplo, as tuplas são um tópico ativo. Sim, havia tuplas antes, mas como uma classe separada, que incluía muitos elementos. Agora ele foi transformado em tuplas, quando podemos criar um método que retorna não 1 objeto, mas vários. Anteriormente, para retornar mais de 1 parâmetro, era necessário declarar um parâmetro de saída / referência ou inventar uma classe separada e arrastá-la ainda mais, mas agora você pode devolvê-lo como uma tupla.

Para resumir!

Muitos desenvolvedores têm essa atitude em relação às mudanças de idioma: até que fomos bem, não sabíamos o que era ruim. O .NET Core é uma fonte aberta, para que qualquer pessoa possa adicionar um recurso e escrever sobre o problema no portal. É claro que existem muitas questões controversas: alguém está esperando por mudanças que parecem completamente desconfortáveis ​​para os outros. Por exemplo, a versão 8 do idioma inclui o controle dos tipos de Referência Nula, e até agora a questão da conveniência é controversa: a inovação foi anunciada em 2 versões anteriores e foi incluída apenas no Core 3.0 final e, por padrão, esse recurso está desabilitado, pois sua inclusão pode levar a à repartição de um grande projeto. Porém, ao escrever um aplicativo a partir do zero, é extremamente útil e permite tornar o aplicativo mais limpo e transparente.

Na minha opinião, a plataforma que agora é um player forte no mundo do desenvolvimento com um limiar de entrada bastante baixo (há ainda mais baixo, mas trabalhar com ela é mais difícil). Obviamente, escolher uma plataforma significa trabalhar com vários fatores e depender de objetivos. Se esse é um aplicativo complexo que processa terabytes de dados e precisa ser verificado antes do byte, isso é uma programação complicada para as vantagens. Mas você precisa entender que esse é meio ano para desenvolvimento e dois para revisão, e quando ele for lançado, ele ficará obsoleto. Além disso, não há muitas pessoas que codificam vantagens. Se estamos falando de desenvolvimento corporativo, quando o tempo de lançamento é de duas semanas, faz sentido escolher outra tecnologia que ajude a obter o resultado final mais rapidamente (Java, .NET, php).