Ewiger Sonnenschein des Clean .NET

Als ich vor 10 Jahren anfing, mit .NET Framework 3.5 (Sprachversion 3.0) zu arbeiten, war die Funktionalität für mich äußerst eingeschränkt, als ich mit SharePoint 2010 anfing. Nach und nach studierte ich eine größere Bandbreite von Technologien und verfolgte die Entwicklung von .NET Ich kann das enorme Wachstum von einem zweifelhaften Konkurrenten zu Java hin zu einer coolen plattformübergreifenden Plattform mit der Fähigkeit, Daemons für Linux zu entwickeln (und sie waren ausschließlich für Windows gedacht), feststellen. Als ich zum ersten Mal auf Technologie gestoßen bin, schien mir natürlich alles zu reichen: Schließlich gab es Möglichkeiten, das zu implementieren, was beabsichtigt war. Aber jetzt, da wir Erfahrung mit der Arbeit auf verschiedenen Plattformen und ihren verschiedenen Versionen haben, können wir bereits spekulieren, dass das Leben in diesen fernen Zeiten ein Schmerz war.

Wenn es im Allgemeinen interessant ist, mental in diese Zeit zurückzukehren und gemeinsam über .NET im Kontext von "Es war - Es ist geworden" nachzudenken, dann lade ich Sie ein, sich mit cat zu beschäftigen. Ich denke, es wird sowohl für diejenigen interessant sein, die in letzter Zeit programmieren und nicht über die Funktionen früherer Versionen Bescheid wissen, als auch für diejenigen, die sich Nostalgie hingeben möchten.

Alter der Schmerzen

Als ich mit der Entwicklung begann, arbeitete SharePoint 2010 mit .NET Framework 3.5 und enthielt bereits eine Menge: LINQ wurde angezeigt und es gab primitives AJAX. Die Plattform war jedoch sehr begrenzt, da es schwierig war, sie zu erweitern, und es gab damals einfach keine geeigneten Tools.

Schmerz 1: Erstellen einer einzelnen Anwendung

Dann basierte die Technologie zur Entwicklung von Webparts für den "Ball" auf WebForms, wobei jedes Webpart im Wesentlichen eine separate Anwendung war. Persönlich war es für mich unrealistisch, eine einzelne Anwendung wie diese zu erstellen, da bei der Entwicklung des Webparts jeder seinen eigenen Kontext für die Verbindung mit der Datenbank initialisiert - es stellte sich heraus, dass es unmöglich war, einen einzelnen Kontext zu erstellen. Nun, um beispielsweise Daten aus der Datenbank auf den Seiten anzuzeigen, habe ich SqlDataSource verwendet (indem ich separat eine Verbindung zur Datenbank im Widget herstellte), und um eine Verbindung zu 3-4 Tabellen herzustellen, hatte ich 3-4 DataSource im Widget, was natürlich der Fall ist , beeinflusst die Geschwindigkeit beim Laden von Seiten. Zu diesem Zeitpunkt war das ADO.NET-Entity-Framework bereits erschienen, es war jedoch unpraktisch, es in SharePoint bis Version 4.1 zu verwenden, da Es gab Probleme mit dem Zusammenspiel der Produkte.

Schmerz 2: Unzugänglichkeit von Unterstützung und Mustern

Webparts für SP 2010 Wir haben über die Technologie zum Erstellen von Webparts für SP 2007 geschrieben, weil Es gab keine Vorlagen oder Unterstützung für das Studio 2008. Mit der Veröffentlichung von Visual Studio 2010 erschienen nach und nach ihre Vorlagen und es wurde einfacher zu arbeiten: Es wurde möglich, Listendefinitionen zu erstellen und sie aus dem Studio heraus zu codieren, um eine Website-Vorlage zu erstellen (kodieren Sie den gewünschten Inhaltstyp und die gewünschte Listenbeschreibung). Früher wurde dies alles von Hand durch Bearbeiten von XML-Dateien erledigt, und dies war zweifellos ein Schmerz für diejenigen, die gerade in die .NET-Entwicklung eintauchten, da die Person nicht verstand, welche Art von Datei er bearbeitete und zu welchem ​​Zweck, sondern sich nur darauf konzentrierte Onkels Worte aus dem Forum.

Schmerz 3: Asynchronität ...

In .NET Framework 3.5 gab es keine Asynchronität in der Form, die wir jetzt kennen, und wir mussten bestimmten Code in einem anderen Thread ausführen, über Delegate-Handler kommunizieren, und in WinForms war es möglich, den Hintergrund eines Arbeiters zu verwenden (d. H. Den zweiten Prozess) parallel laufen, in dem gearbeitet wurde). Es stellte sich heraus, dass die Programmierung von asynchronen Anwendungen existierte, aber ihre Implementierung war für June unverständlich.

In .NET Framework 4 wurde die Task Parallel Library angezeigt, und daher wurden auch Tasks angezeigt, d. H. Wir konnten keine Delegierten deklarieren, sondern eine Aufgabe ausführen, ihr eine Aktion übergeben und sie in einem parallelen Thread ausführen, den Status / Zustand kennen und, falls erforderlich, ein Signal über ihre Implementierung erhalten. Es war ein Fortschritt für die parallele Entwicklung, wenn Sie eine große Menge von Daten verarbeiten müssen, da zuvor eine größere Anzahl von Eingaben erforderlich war.

... und gefrorene Fenster

Sie müssen verstehen, dass sich das Web stark von der Entwicklung von Konsolenanwendungen unterscheidet (hier ist keine globale Benennung gemeint, sondern die, die wir bei der Beschreibung der folgenden Themen verwenden: Nicht speziell ConsoleApp, sondern alle Anwendungen, die auf der Betriebssystemoberfläche ausgeführt werden). In einer Konsolenanwendung werden alle Vorgänge standardmäßig synchron ausgeführt. Bei einer langen Verarbeitungszeit „friert“ die Schnittstelle ein, als ob die Anwendung eingefroren wäre. Um nicht zu spüren, dass das Programm nicht reagiert, haben wir alle Vorgänge in einem separaten Thread ausgeführt und Fortschrittsbalken eingegeben: Auf diese Weise sah der Benutzer die Anwendungsaktivität, und es war beispielsweise möglich, über einen Delegaten von einem anderen Thread aus zu steuern.

Schmerz 4: Bereitstellung kommt

Auch in .NET Framework 3.5 gab es eine andere schmerzhafte Technologie - MS AJAX. UpdatePanel-Inhalte wurden über das Backend aktualisiert, während alles andere überhaupt nicht neu erstellt wurde. In SharePoint arbeitete er aufgrund der Besonderheiten der Initialisierung von Steuerelementen im Seitenlebenszyklus sehr schief. Hier hat es nach dem ersten Post-Back (manchmal nach dem zweiten) funktioniert, und im Allgemeinen war es schwierig, MS AJAX beim ersten Mal zum Laufen zu bringen, obwohl es ganz einfach von sauberem WebForm UpdatePannel verwendet wurde. Und es war nicht möglich, klassisches AJAX (XMLHttpRequest) in dieser Version des "Balls" zu verwenden, da für jede Aktion ein separater Handler auf den Rücken geschrieben und in einer Packung jedes Webparts aufgehängt werden musste. Gleichzeitig war es nicht immer möglich, diese Funktionalität aufzuheben.

Als ich parallel mit anderen auf WebForms geschriebenen Anwendungen für "Near-Ball" -Aufgaben arbeitete, war ich überrascht, dass das Problem der Bereitstellung eines Projekts auf SP nur für SP ein Problem ist. Die restlichen Anwendungen wurden im Moment initialisiert: Das Fenster wurde geladen und es funktioniert (magisch!). Im Ballon dauerte die Bereitstellung 2 bis 3 Minuten, und Sie befinden sich in einem konstanten Zyklus:



Im Allgemeinen wurde allen klar, dass es sich um einen langen Prozess der Bereitstellung und Kurzurlaube handelte. Aber ich bin dankbar für diesen Schmerz - also habe ich gelernt, mehr Code zu generieren und weniger Fehler in einer Entwicklungs-Iteration zu machen.

Schmerz 5: Windows und nichts als Windows

Zu dieser Zeit positionierte sich .NET noch als Entwicklungsplattform für Windows. Ja, es gab ein Mono-Projekt, das im Wesentlichen ein „Fahrrad“ von .NET unter Linux war, aber es war eine alternative Version des Hauptrahmens und immer noch auf der Projektseite www.mono-project.com/docs/. About-Mono / Kompatibilität ) listet Funktionen auf, die von der Version des Frameworks nicht hinzugefügt wurden. Als Sie etwas für Linux entwickelten, war es alles andere als benutzerfreundlich, da Mono nicht über diese Unterstützung und Community verfügte. Wenn Sie sich einigen nicht realisierten Dingen zuwandten, konnte der Code einfach kaputt gehen. Das heißt, wenn Sie es zunächst nicht für Mono entwickeln, können Sie im Prinzip keinen plattformunabhängigen Code schreiben. Ich schließe die Bedeutung dieses Projekts für die Entwicklung von .NET als Ganzes nicht aus, denn ohne es wäre Core nicht erschienen, aber ich persönlich hatte keine Kampferfahrung damit.

Age of Pros (Schmerzmittel)

Die reine Verwendung der neuesten .NET-Version in ihren Projekten beseitigt fast alle diese Probleme. Es gibt jetzt viele Vorteile im Framework, aber dann werden wir über die Vorteile der Bindung an Core as sprechen Ich habe mit ihm gearbeitet.

Plus 1: Leistung

Mit dem Erscheinen von .NET Core wurde es möglich, vertraute Operationen viel kühler und schneller durchzuführen. Die endgültigen Anwendungen darauf arbeiten laut einigen Daten bis zu 5000-mal schneller als ihre Gegenstücke auf dem .NET Framework. Das Kompilieren und Starten dauert jedoch manchmal länger - "lange nutzen - schnell fahren".

Plus 2: Plattformübergreifend

Das Hauptplus von .NET Core ist die Tatsache, dass der geschriebene Code gleichzeitig unter Windows, Linux und Mac funktioniert. In diesem Fall können Sie über die Nachrichtenwarteschlange eine Anwendung in die Microservice-Architektur des asynchronen Protokollierungsdienstes schreiben. Ich erinnere mich, wie ich, ein Entwickler, der hauptsächlich unter Windows schreibt, Dämonen (Dienste) unter Linux schrieb, und sie stabil, schnell und zum ersten Mal arbeiteten und das ganze System zusammenarbeitete: in der Anwendung, dem API-Dienst und der Nachrichtenwarteschlange selbst. Es ist nur Platz, wenn Sie in Ihrer gewohnten Sprache auf einer Plattform schreiben, die ursprünglich nicht für dieses Betriebssystem entwickelt wurde!

Plus 3: Asynchron von allem

Jetzt ist es möglich, Backing nicht parallel, nicht multithreaded, sondern vollständig asynchron (!) Zu schreiben, wodurch Sie einzelne Tasks aus dem Hauptstream in spezielle asynchrone Methoden oder Codeblöcke entfernen können. Dies ermöglicht es Ihnen wiederum, schönen, sauberen Code zu schreiben, der frei von sperrigen Konstruktionen ist: Es ist leicht zu verstehen, asynchrone Methoden werden so synchron geschrieben und funktionieren so, wie sie sollten.

Plus 4: Entladen von Bibliotheken und geringerer Speicherverbrauch

Wenn Sie sich die aktuelle 8. Version von C # ansehen, dann hat sie viel Zucker und die Änderungen sind faszinierend. Erstens, bevor wir die ursprünglich entladene DLL nicht dynamisch entladen konnten (wir haben die Bibliotheken dynamisch in das Projekt geladen, aber sie blieben im Speicher hängen). Mit der Veröffentlichung von 3rd Core wurde es möglich, Bibliotheken abhängig von den Zielen dynamisch zu laden und zu entladen. Wenn wir beispielsweise eine Dateisuchanwendung erstellen möchten und der Benutzer die XML-Erweiterung auswählt, laden wir den XML-Parser dynamisch für Dokumente und suchen in seiner Struktur. Wenn wir nach JSON suchen möchten, beginnen wir mit der Suche nach seinen Body-Libraries, die von bestimmten Bedingungen abhängig sind, und es ist nicht erforderlich, sie im RAM zu belassen. Und ja. Die Anwendung hat aufgehört, ständig Speicher zu verbrauchen. Wenn wir die Assembly entladen, geben wir alle Ressourcen frei, die an dieser Assembly haften.

Plus 5: Tupel

Die Sprache ist noch jung, lebendig und entwickelt sich aktiv. Die neueste Version hat eine Menge cooler Dinge hinzugefügt: Zum Beispiel sind Tupel ein aktives Thema. Ja, es gab Tupel zuvor, aber als separate Klasse, die viele Elemente enthielt. Jetzt wurde es in Tupel umgewandelt, wenn wir eine Methode erstellen können, die nicht 1 Objekt, sondern mehrere zurückgibt. Bisher war es für die Rückgabe von mehr als einem Parameter erforderlich, einen Ausgabe- / Referenzparameter zu deklarieren oder eine separate Klasse zu erfinden und weiter zu ziehen. Jetzt können Sie sie jedoch als Tupel zurückgeben.

Um es zusammenzufassen!

Viele Entwickler haben eine solche Einstellung zu Sprachänderungen: Bis wir gut abschneiden, wissen wir nicht, was schlecht ist. .NET Core ist Open Source, sodass jeder selbst ein Feature hinzufügen und über seine Schmerzen im Portal schreiben kann. Natürlich gibt es viele kontroverse Themen: Jemand wartet auf Veränderungen, die anderen völlig unangenehm erscheinen. Zum Beispiel enthält die Version 8 der Sprache die Steuerung von nullbaren Referenztypen, und bisher ist die Bequemlichkeitsfrage umstritten: Die Innovation wurde in 2 früheren Versionen angekündigt und war nur im endgültigen Core 3.0 enthalten, und standardmäßig ist diese Funktion deaktiviert, da ihre Aufnahme dazu führen kann zum Zusammenbruch eines Großprojekts. Wenn Sie jedoch eine Anwendung von Grund auf neu schreiben, ist dies äußerst nützlich und ermöglicht es Ihnen, die Anwendung sauberer und transparenter zu gestalten.

Meiner Meinung nach ist die Plattform, die es jetzt gibt, bereits ein starker Akteur in der Entwicklungswelt mit einer relativ niedrigen Einstiegsschwelle (es gibt noch niedrigere, aber es ist schwieriger, daran zu arbeiten). Natürlich bedeutet die Wahl einer Plattform, mit einer Reihe von Faktoren zu arbeiten und von Zielen abhängig zu sein. Wenn dies eine komplexe Anwendung ist, die Terabytes an Daten verarbeitet und vor dem Byte überprüft werden muss, ist dies eine komplizierte Programmierung. Sie müssen sich jedoch darüber im Klaren sein, dass dies ein halbes Jahr für die Entwicklung und zwei für die Überarbeitung ist. Wenn es veröffentlicht wird, wird es veraltet sein. Darüber hinaus gibt es nicht viele Menschen, die für Pluspunkte codieren. Wenn es sich um eine Unternehmensentwicklung handelt und die Veröffentlichungszeit 2 Wochen beträgt, ist es sinnvoll, eine andere Technologie zu wählen, mit der das Endergebnis schneller erzielt werden kann (Java, .NET, PHP).