Lorsque j'ai commencé à travailler avec .NET Framework 3.5 (version linguistique 3.0) il y a 10 ans, pour moi, ses fonctionnalités étaient extrêmement limitées, comme j'ai commencé avec SharePoint 2010. En étudiant progressivement un éventail plus large de technologies et en suivant le développement de .NET, j'ai Je peux noter son énorme croissance d'un concurrent douteux à Java à une plate-forme cool avec la capacité de développer des démons pour Linux (et il était destiné exclusivement à Windows). Bien sûr, lorsque j'ai découvert la technologie pour la première fois, il semblait que tout était suffisant: après tout, il y avait des moyens de mettre en œuvre ce qui était prévu. Mais maintenant, ayant une expérience de travail sur différentes plates-formes et leurs différentes versions, nous pouvons déjà spéculer que la vie était une douleur dans ces temps lointains.
En général, s'il est intéressant de revenir mentalement à cette époque et de réfléchir ensemble sur .NET dans le contexte de «C'était - c'est devenu», alors je vous invite à cat. Je pense que cela sera intéressant à la fois pour ceux qui codent récemment et ne connaissent pas les fonctionnalités des versions précédentes, et pour ceux qui veulent se livrer à la nostalgie.
Age of Pain
Lorsque j'ai commencé à développer, SharePoint 2010 a travaillé sur le .NET Framework 3.5 et en comprenait déjà beaucoup: LINQ est apparu et il y avait AJAX primitif. Mais il était très limité par la plate-forme, car il était assez difficile de l'étendre, et il n'y avait tout simplement pas d'outils adéquats à l'époque.
Douleur 1: Création d'une seule applicationEnsuite, la technologie de développement de composants WebPart pour la "boule" était basée sur des formulaires Web, chaque composant WebPart étant essentiellement une application distincte. Personnellement, il n'était pas réaliste pour moi de créer une seule application comme celle-ci, car lors du développement du composant WebPart, chacun initialise son propre contexte pour se connecter à la base de données - il s'avère qu'il était impossible de créer un seul contexte. Eh bien, par exemple, pour afficher les données de la base de données sur les pages, j'ai utilisé SqlDataSource (en me connectant à la base de données dans le widget séparément), et pour me connecter à 3-4 tables, j'avais 3-4 DataSource sur le widget, qui, bien sûr , a influencé la vitesse de chargement des pages. À ce moment-là, ADO.NET Entity Framework était déjà apparu, mais il n'était pas pratique de l'utiliser dans SharePoint jusqu'à la version 4.1, car il y avait des problèmes avec l'interaction des produits.
Douleur 2: inaccessibilité du soutien et des modèlesLes composants WebPart pour SP 2010, nous avons écrit sur la technologie de création de composants WebPart SP 2007, car il n'y avait pas de modèles ou de support pour le studio 2008. Progressivement, avec la sortie de Visual Studio 2010, leurs modèles sont apparus, et il est devenu plus facile de travailler: il est devenu possible de faire des définitions de liste et de les coder depuis le studio, de créer un modèle de site web (encoder le type de contenu et la description de liste souhaités). Auparavant, tout cela était fait à la main en éditant des fichiers XML, et cela, sans aucun doute, était une douleur pour ceux qui venaient de plonger dans le développement .NET, car la personne ne comprenait pas quel type de fichier il éditait et dans quel but, mais se concentrait uniquement sur Les mots de l'oncle du forum.
Douleur 3: asynchronie ...Dans le .NET Framework 3.5, il n'y avait pas d'asynchronie sous la forme que nous connaissons maintenant, et nous devions exécuter un certain code dans un autre thread, communiquer via des gestionnaires délégués, et dans WinForms, il était possible d'utiliser l'arrière-plan du travailleur (c'est-à-dire le deuxième processus fonctionnant en parallèle dans lequel le travail a été effectué). Il s'avère que la programmation d'applications asynchrones existait, mais leur mise en œuvre était au-delà de la compréhension de juin.
Dans le .NET Framework 4, la bibliothèque parallèle de tâches est apparue et, par conséquent, les tâches sont également apparues, c'est-à-dire nous ne pouvions pas déclarer de délégués, mais faire une tâche, lui passer une action et l'exécuter dans un thread parallèle, connaissant l'état / l'état et, si nécessaire, recevoir un signal sur sa mise en œuvre. C'était un progrès pour le développement parallèle, lorsque vous avez besoin de traiter une grande quantité de données, car avant cela était fait avec une plus grande barre d'entrée.
... et des fenêtres figéesVous devez comprendre que le Web est très différent du développement d'applications de console (ici, nous ne parlons pas de nom global, mais celui qui est utilisé pour décrire ces thèses: pas spécifiquement ConsoleApp, mais toutes les applications qui s'exécutent dans l'interface OS). Dans une application console, toutes les opérations sont effectuées de manière synchrone par défaut, et si le temps de traitement est long, l'interface se "fige" comme si l'application était gelée. Afin de ne pas sentir que le programme ne répond pas, nous avons effectué toutes les opérations dans un thread séparé et entré des barres de progression: de cette façon, l'utilisateur a vu l'activité de l'application, et il était possible de contrôler à partir d'un autre thread via un délégué, par exemple.
Douleur 4: le déploiement arriveToujours dans le .NET Framework 3.5, il y avait une autre technologie douloureuse - MS AJAX. Le contenu UpdatePanel a été mis à jour depuis le backend, tandis que tout le reste n'a pas été reconstruit du tout. Dans SharePoint, il a travaillé de manière très tordue en raison des spécificités de l'initialisation des contrôles dans le cycle de vie de la page. Ici, cela a fonctionné pour nous après le premier post-back (parfois après le second), et en général, il était difficile de faire bien fonctionner MS AJAX la première fois, bien qu'il ait été utilisé tout simplement avec WebForm UpdatePannel propre. Et il n'était pas possible d'utiliser l'AJAX classique (XMLHttpRequest) dans cette version de la "boule", car pour chaque action, il était nécessaire d'écrire un gestionnaire distinct à l'arrière et de les accrocher dans un pack de chaque composant WebPart. Dans le même temps, il n'a pas toujours été possible de liquider cette fonctionnalité.
Quand en parallèle je travaillais avec d'autres applications écrites sur WebForms pour des tâches "near-ball", j'ai été surpris que le problème du déploiement d'un projet sur SP ne soit un problème que pour SP. Le reste des applications ont été initialisées pour le moment: la fenêtre chargée, et ça marche (magique!). Dans le ballon, le déploiement a duré de 2 à 3 minutes, et vous êtes dans un cycle constant:
En général, tout le monde a compris qu'il s'agissait d'un long processus de déploiement et de mini-pauses. Mais je suis reconnaissant pour cette douleur - j'ai donc appris à générer plus de code et à faire moins d'erreurs en une seule itération de développement.
Douleur 5: Windows et rien que WindowsÀ cette époque, .NET se positionnait toujours comme une plate-forme de développement pour Windows. Oui, il y avait un projet Mono, qui, en substance, était une «bicyclette» de .NET sous Linux, mais c'était une version alternative du Framework principal, et toujours sur la page du projet
www.mono-project.com/docs/ about-mono / compatibilité ) répertorie les fonctionnalités qui n'y sont pas ajoutées par la version du Framework. Lorsque vous avez développé quelque chose pour Linux, c'était loin d'être convivial, car Mono n'avait pas ce support et cette communauté, et si vous vous tourniez vers des choses non réalisées, le code pourrait simplement casser. Autrement dit, si vous ne le développez pas initialement pour Mono, vous ne pouvez pas écrire de code indépendant de la plate-forme en principe. Je n'exclus pas l'importance de ce projet pour le développement de .NET dans son ensemble, car sans lui Core ne serait pas apparu, mais personnellement, je n'avais aucune expérience de combat avec.
Age of Pros (Painkiller)L'utilisation même de la dernière version pure de .NET dans leurs projets élimine presque tous ces problèmes. Il y a maintenant de nombreux avantages dans le Framework, mais nous parlerons ensuite des avantages de la liaison avec Core, comme J'ai travaillé avec lui.
Plus 1: performancesLorsque .NET Core est apparu, il est devenu possible de faire des opérations familières beaucoup plus cool et plus rapidement. Les applications finales fonctionnent selon certaines données jusqu'à 5000 fois plus rapidement que leurs homologues sur le .NET Framework. Mais la compilation et le lancement prennent parfois plus de temps - «attelez-vous longtemps - conduisez vite».
Plus 2: multiplateformeLe principal avantage de .NET Core est le fait que le code écrit fonctionne simultanément sur Windows, Linux et Mac. Dans ce cas, vous pouvez écrire une application sur l'architecture de microservice du service de journalisation asynchrone via la file d'attente de messages. Je me souviens comment moi, un développeur qui écrit principalement sous Windows, j'ai écrit des démons (services) sous Linux, et ils ont travaillé de manière stable, rapide et la première fois, et tout le système a travaillé en tandem: dans l'application, le service API et la file d'attente de messages elle-même. C'est juste de l'espace, lorsque vous écrivez dans votre langue habituelle sur une plateforme qui n'a pas été initialement conçue pour ce système d'exploitation!
Plus 3: asynchronisation de toutIl est maintenant possible d'écrire des sauvegardes non en parallèle, non multithread, mais complètement asynchrones (!), Ce qui vous permet de supprimer des tâches individuelles du flux principal dans des méthodes asynchrones spéciales ou des blocs de code. Ceci, à son tour, vous permet d'écrire un code beau et propre, exempt de constructions volumineuses: il est facile à comprendre, les méthodes asynchrones sont écrites comme synchrones et fonctionnent comme elles le devraient.
Plus 4: déchargement des bibliothèques et consommation de mémoire moins intensiveSi vous regardez la 8e version actuelle de C #, elle contient beaucoup de sucre et les changements sont fascinants. Tout d'abord, avant, nous n'avions pas la possibilité de décharger dynamiquement la DLL initialement déchargée (nous avons chargé dynamiquement les bibliothèques dans le projet, mais elles sont restées suspendues en mémoire). Avec la sortie de 3rd Core, il est devenu possible de charger et décharger dynamiquement des bibliothèques en fonction des objectifs. Par exemple, si nous voulons créer une application de recherche de fichiers et que l'utilisateur sélectionne l'extension XML, nous chargeons dynamiquement l'analyseur XML pour les documents et recherchons dans son arborescence. Si nous voulons rechercher par JSON, alors nous commençons à rechercher par son corps - des bibliothèques qui dépendent de certaines conditions, et il n'est pas nécessaire de les conserver dans la RAM. Et oui. L'application a cessé de consommer constamment de la mémoire. Lorsque nous déchargeons l'assembly, nous libérons toutes les ressources qui s'accrochent à cet assembly.
Plus 5: tuplesLa langue est encore jeune, dynamique et en plein développement. La dernière version a ajouté beaucoup de choses intéressantes: par exemple, les tuples sont un sujet actif. Oui, il y avait du tuple auparavant, mais en tant que classe distincte, qui comprenait de nombreux éléments. Maintenant, il a été transformé en tuples, quand nous pouvons créer une méthode qui renvoie non pas 1 objet, mais plusieurs. Auparavant, pour renvoyer plus d'un paramètre, il était nécessaire de déclarer un paramètre de sortie / référence, ou d'inventer une classe distincte et de la faire glisser plus loin, mais maintenant vous pouvez le retourner en tant que tuple.
Pour résumer!De nombreux développeurs ont une telle attitude envers les changements de langue: jusqu'à ce que nous ayons bien fait, nous ne savions pas ce qui était mauvais. .NET Core est une source ouverte, donc tout le monde peut ajouter une fonctionnalité lui-même et écrire sur son problème sur le portail. Il y a, bien sûr, beaucoup de questions controversées: quelqu'un attend des changements qui semblent complètement inconfortables pour les autres. Par exemple, la version 8 du langage inclut le contrôle des types de référence Nullable, et jusqu'à présent, la question de la commodité est controversée: l'innovation a été annoncée dans 2 versions précédentes, et n'était incluse que dans le Core 3.0 final, et par défaut cette fonctionnalité est désactivée, car son inclusion peut conduire à la rupture d'un grand projet. Mais lors de l'écriture d'une application à partir de zéro, elle est extrêmement utile et vous permet de rendre l'application plus propre et transparente.
À mon avis, la plateforme qui est maintenant est déjà un acteur important dans le monde du développement avec un seuil d'entrée assez bas (il est encore plus bas, mais y travailler est plus difficile). Bien sûr, choisir une plate-forme signifie travailler avec un certain nombre de facteurs et être dépendant des objectifs. S'il s'agit d'une application complexe qui traite des téraoctets de données et doit être vérifiée avant l'octet, alors c'est une programmation compliquée sur les avantages. Mais vous devez comprendre qu'il s'agit d'un semestre pour le développement et deux pour la révision, et au moment où il sera publié, il deviendra obsolète. De plus, il n'y a pas beaucoup de gens qui codent pour les avantages. Si nous parlons de développement d'entreprise, lorsque le délai de sortie est de 2 semaines, il est logique de choisir une autre technologie qui aide à obtenir le résultat final plus rapidement (Java, .NET, php).