Ich denke, jeder Entwickler, als er zu einem neuen Projekt kam, dachte, dass es schön wäre, in die Vergangenheit zu reisen und den Vätern Ihres Projekts mitzuteilen, dass die Muster nicht nur beim Interview abgefragt werden sollten, sondern auch für das eigentliche Projekt, aber ich im Ernst.
Insbesondere ist dies wahrscheinlich ein Muster, aber eine sehr gute Regel ist, dass das Markup vom Code getrennt werden muss. Dies gilt für die guten alten Web Forms, Asp.Net MVC - schreibt noch jemand Markup auf Razor?), Und Angular ist in einem rauen Unternehmen beliebt.
Wenn Sie schon lange keine Hoffnungslosigkeit mehr in Bezug auf die Front der Ender mehr haben und auf die neuen Angular and React-Modelle umsteigen, dann ...
Ja, meine Herren, die Backend-Entwickler, wir hatten wieder die Hoffnung, dass das über die Jahre erworbene Wissen nicht im Kopf verloren geht. Und diese Hoffnung ist die Blazor-Technologie von Microsoft.
Nachdem ich das Standardprojekt geöffnet hatte, das das Studio beim Erstellen des Blazor-Projekts erstellt hatte, und dann mehrere Artikel angesehen hatte, schlich ich mich in den Gedanken, dass wirklich alles so schlecht ist und der Code und das Markup immer in der gleichen Datei sind, wie hier (im Folgenden werden alle Beispiele basierend auf gezeigt) Blazor Server App-Vorlagenprojekt aus Visual Studio 2019 mit installiertem .Net Core 3.1):
Nichts verwirrt hier?
Meiner Meinung nach hat alles, was mit Rot gefüllt ist, wenig mit dem Inhalt zu tun, den diese Komponente darstellt, und Sie müssen ihn loswerden. Warum?
- Nun, erstens wird der Front-End-Entwickler, der gleichzeitig mit Ihnen an diesem Steuerelement arbeitet, ein wenig durch Symbole verwirrt sein, die für ihn unverständlich sind, und jedes Mal wird er vorsichtig sein und Ihnen Fragen stellen, wenn er etwas an dem von Razor-Markup eingerahmten Code ändern muss .
- Natürlich werden Frontender vorsichtig sein, aber Sie werden mit Sicherheit in regelmäßigen Abständen feststellen, dass Ihre Seite nach einigen Manipulationen nicht wie erwartet oder einfach nicht funktioniert.
- Wenn Sie der Meinung sind, dass Front-End-Entwickler nicht benötigt werden, weil jetzt alles in C # geschrieben werden kann, dann irren Sie sich. In jedem Fall müssen Sie das Steuerelement stilisieren. Dies erfolgt entweder durch den Front-End-Entwickler oder durch den Schriftsetzer, der häufig nicht weiß, was C # ist.
- Auf den ersten Blick scheint der Code klein zu sein und das Layout nicht sehr zu überfrachten. Es täuscht. In einem wachsenden Projekt werden Sie sehr schnell von der Bühne aufsteigen und eine Tech-Demo starten, um „Verdammt, was hier passiert“. Ich bin oft auf die Tatsache gestoßen, dass in SQL Web Controls oder direkt auf der .cshtml-Seite eine SQL-Abfrage in die Datenbank gestellt wurde. Ja, ich mache keine Witze. Sehr oft schreiben erfahrene Entwickler, die Sie gestern in einem Sozialversicherungsinterview gefoltert haben und bereits die SOLID-Prinzipien kennen, die Geschäftslogik von morgen direkt im Markup.
Ich glaube, ich habe Sie schon genug erschreckt. Jetzt werde ich Ihnen sagen, wie Sie die oben genannten Probleme vermeiden können. Dies geschieht umso einfacher. Und es ist großartig, wenn Sie beim Erstellen einer neuen Razor-Komponente in der Regel die folgenden Ansätze verwenden. Also der erste Ansatz.
Basisklasse
Der erste und bis vor kurzem einzige Ansatz.
Für das Steuerelement aus dem obigen Beispiel erstellen Sie eine Basisklasse, in der sich die gesamte Anzeigelogik befindet. Erstellen Sie eine neue Datei mit der Vorlage
[Name der Kontrolle] .razor.cs
Hier hilft uns das Studio und baut aus zwei Dateien etwas wie im Bild unten auf:
Wie Sie sehen, ist das Studio ziemlich intelligent und hat selbst verstanden, was Sie von ihm wollen. Das Steuerelement wurde mit der Datei gruppiert, in der wir unseren Code platzieren möchten.
Wenn Sie gerade eine neue Datei öffnen, wird der Name der FetchData- Klasse mit einer roten Wellenlinie unterstrichen. Alles ist wahr, denn trotz der Tatsache, dass Sie in FetchData.razor nirgendwo Klassendeklarationen mit dem Namen FetchData sehen , wird dies später nach dem Kompilieren des Projekts angezeigt es ist niedriger und daher ist der Klassenname FetchData bereits reserviert. Wir haben keine andere Wahl, als die Konvention zu verwenden, dass wir die Anzeigelogik (und nur sie !!!) in die FetchDataBase-Klasse einfügen, dh der Klassenname wird von der Vorlage gebildet:
[ControlName] Base
Natürlich können Sie verwirrt sein und Ihren eigenen statischen Analysator schreiben, der für jede Komponente nach solchen Dateien sucht. Warum nicht?
Als Nächstes müssen wir diese Klasse von ComponentBase erben. Vergessen Sie nicht hinzuzufügen
using Microsoft.AspNetCore.Components ;
Und hier ist was wir haben:
Wow, die Klasse ist jetzt bereit, die Anzeigelogik hierher zu übertragen. Wir haben jetzt die Möglichkeit, sie vollständig in C # zu schreiben. :)
Während die Razor-Komponente selbst nichts über unsere Datei weiß, weiß nur Visual Studio, dass sie etwas gemeinsam haben.
Also mache den folgenden Trick:
Wir haben die Razor-Komponente von der FetchDataBase- Klasse geerbt .
Lassen Sie sich von C # -Code, der noch in FetchData.razor vorhanden ist, nicht stören.
Im Moment werden wir die gesamte Anzeigelogik in unsere sogenannte Code-Behind-Datei übertragen:
Was ist passiert? Zuerst haben wir mit -und hinzugefügt. Auf Razor-Steuerelementen werden Sie sie praktisch nicht sehen, da es üblich ist, sie zu _Imports.razor hinzuzufügen . Es sind bereits einige der am häufigsten verwendeten hinzugefügt.
Als nächstes spritzen wir durch das Grundstück, wie Sie sehen können, funktioniert unser Lieblings-DI einwandfrei.
Sie müssen die implementierte Eigenschaft nur mit dem Attribut [Inject] kennzeichnen. In der Razor-Komponente wurde sie mit Inject gekennzeichnet . Das heißt, die Änderungen sind minimal.
Nun, dann folgt die Eigenschaft, in die wir die angezeigten Informationen laden. Sie müssen mindestens geschützt sein (da das Razor-Steuerelement von der aktuellen Klasse erbt). Oder public, wenn Sie die Initialisierung von außen ermöglichen möchten, müssen Sie sie in diesem Fall weiterhin mit dem Attribut [Parameter] kennzeichnen. In früheren Versionen von Blazor war es ziemlich geschützt , aber jetzt schimpft der Studio Analyzer Sie dafür.
Im Prinzip können Sie dieser Klasse einen Konstruktor hinzufügen und dort einige Arbeiten ausführen. Dies wird jedoch nicht empfohlen. Es ist besser, die gesamte Initialisierungslogik in der OnInitializedAsync () - Methode zu platzieren
Das ist alles, was in FetchData.razor verbleibt
Es gab vereinzelte Razor-Markups, aber wie könnte es anders sein, müssen wir unsere Daten trotzdem irgendwie anzeigen. Aber reiner C # -Code ist komplett verschwunden. Und das ist meiner Meinung nach großartig. Ich rate Ihnen, zunächst einen ähnlichen Ansatz zu verfolgen, und dann werden weder Sie noch Ihre Kollegen Ihren Kopf wieder in den Griff bekommen, wenn Ihre Kontrolle zu groß wird.
Das Wichtigste ist, ob es überhaupt funktioniert. Lassen Sie uns nun Folgendes überprüfen:
Großartig, es ist, als hätten sie nichts kaputt gemacht =)
Teilklasse
Und so wird der zweite Ansatz, der vor kurzem erschien ( https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.1#partial-class-support ), aber höchstwahrscheinlich vollständig ersetzen vorherige. Auf Wunsch von Mitarbeitern wurde in .Net Core 3.1 die Möglichkeit hinzugefügt, eine Teilklasse für Razor-Steuerelemente zu erstellen. Wir lassen also fast alles so, wie es im vorherigen Ansatz der Fall war, aber jetzt müssen wir nicht mehr von ComponentBase erben, und die Klasse kann genauso wie die Komponente aufgerufen werden, dh ihre Signatur lautet wie folgt:
öffentliche Teilklasse [ComponentName]
Wie Sie unten sehen können, sind die Änderungen minimal. Im Code dahinter haben wir die Vererbung von ComponentBase entfernt und die Klasse als partiell markiert
Die Markup-Datei ist ebenfalls ein wenig vereinfacht, wir haben auch die Vererbung von FetchDataBase entfernt, da diese Klasse aufgrund ihrer Nutzlosigkeit nicht mehr existiert.
Wie Sie sehen, gibt es zwei Ansätze, um Ihr Markup sauber zu halten. Welches du wählst, liegt ganz bei dir. Leider wäre es schön, wenn das Studio beim Erstellen einer neuen Komponente sofort Code-Behind generieren würde. Jetzt wird dies aktiv diskutiert und, wie die Entwickler sagen, in Zukunft eine solche Wahrscheinlichkeit hinzugefügt, wenn es eine Nachfrage dafür gibt, und das wird es mit Sicherheit sein.
Was wird nun aus unserer Razor-Komponente:
Es ist bekannt, nicht wahr?) Jeder, der einmal seine Razor Asp.Net MVC-Komponenten erstellt hat, wird den Inhalt der automatisch generierten Datei als sehr vertraut empfinden.
Ich hoffe, Sie haben heute von meinem ersten Artikel über Habr etwas mehr über Blazor gelernt. Hinterlasse unten Kritik, Fragen und Wünsche für neue Artikel =)