Globale Usings in C# 10 und .NET 6 in 10 Minuten oder weniger

Das Wiederholungsproblem

[0:17 - 1:50] Tim beginnt mit einer neuen .NET 6 Konsolen-App und erstellt einen Datenordner, der eine PersonModel klasse enthält. Die Referenzierung dieser Klasse aus Program.cs erfordert die erwartete using GlobalUsings.Data;-Zeile am Anfang der Datei. Das Hinzufügen einer zweiten Klasse, die ebenfalls PersonModel benötigt, bedeutet, dass die gleiche Using-Zeile auch am Anfang dieser Datei hinzugefügt werden muss. Bei einem halben Dutzend Klassen wird derselbe Import ein halbes Dutzend Mal geschrieben.

Dies ist genau die Situation, für die global using entwickelt wurde. Jeder Namespace, Typ oder statische Klasse, von der das gesamte Projekt abhängt, kann einmal deklariert und jeder Datei zur Verfügung gestellt werden, ohne dass eine Wiederholung pro Datei nötig ist.

Ein Using auf globaler Ebene fördern

[1:50 - 2:24] Die Syntax ist ein einzelnes Schlüsselwort vor der bestehenden Direktive:

global using GlobalUsings.Data;

global using GlobalUsings.Data;

Diese eine Zeile, in einer beliebigen .cs-Datei im Projekt platziert, macht GlobalUsings.Data in jeder anderen Datei im gleichen Projekt verfügbar. Die anderen Klassen, die bisher ihre eigene Using-Zeile für PersonModel benötigten, benötigen diese nicht mehr; der Typ wird automatisch aufgelöst. Der Geltungsbereich endet an der Projektgrenze, sodass beim Referenzieren von Klassen aus einem Schwesterprojekt weiterhin die normale Projektreferenz sowie das eigene globale oder dateispezifische using erforderlich ist.

Was dies nicht tut, ist zu verbergen, woher Typen stammen. Der Compiler löst dennoch PersonModel zu seinem Namespace auf; der Namespace ist lediglich voreingebunden. Das Verhalten zur Laufzeit ist identisch mit dem Schreiben des gleichen using am Anfang jeder Datei.

Usings in einer Datei zentralisieren

[2:24 - 3:32] Das Verteilen von globalen using-Direktiven über zufällige Dateien ist technisch möglich, jedoch operationell unordentlich. Wenn ein neues Teammitglied sieht, dass PersonModel ohne sichtbaren Import aufgelöst wird, muss es das Projekt durchsuchen, um herauszufinden, wo es global gemacht wurde. Die sich entwickelnde Konvention ist, alle globalen usings in einer einzigen Datei am Projektspeicherort zu behalten, die etwas vorhersehbares wie Usings.cs oder GlobalUsings.cs heißt:

// Usings.cs at the project root
global using GlobalUsings.Data;
global using System.Text.Json;
global using System.Collections.Concurrent;

// Usings.cs at the project root
global using GlobalUsings.Data;
global using System.Text.Json;
global using System.Collections.Concurrent;

Die Datei enthält nichts anderes. Jeder, der dem Projekt beitritt, weiß genau, wo er nachsehen muss, um zu sehen, was global verfügbar ist. Dies passt zu dateibasierten Namespaces und anderen features, die den Zeremonienschnitt erleichtern, die in den letzten C#-Versionen eingeführt wurden, und alle zielen darauf ab, das Projektgerüst auf einen Blick leichter lesbar zu machen.

Globale Using-Statik für Methodenimporte

[3:32 - 4:50] Die globale using-Direktive lässt sich mit der statischen Form von using kombinieren, die früher hinzugefügt wurde. Die Kombination ermöglicht es, das Klassenpräfix von einem statischen Klassenmitglied im gesamten Projekt nicht mehr zu verwenden. Der motivierende Fall, den Tim zeigt, ist Console.WriteLine:

global using static System.Console;

global using static System.Console;

Mit dieser einzigen Zeile in der zentralisierten Using-Datei wird Console.WriteLine("hello") einfach überall im Projekt zu WriteLine("hello"). Dasselbe Muster funktioniert für Mathe-Hilfsmittel (global using static System.Math ermöglicht es Ihnen, Sqrt(x) ohne das Präfix zu schreiben) und für jede andere statische Klasse, auf die Ihr Code stark angewiesen ist.

Dies ist die Form, bei der Tim am vorsichtigsten ist. Das Fallenlassen des Klassenpräfixes ist ein Gewinn in der Lesbarkeit, wenn die Methoden offensichtlich sind, aber es kann zu Verwirrung führen, wenn zwei statische Klassen Methoden mit demselben Namen bereitstellen. Ein Leser, der einen bloßen WriteLine-Aufruf sieht, muss der zentralen Datei vertrauen, anstatt die Quelle im Kontext zu sehen.

Wenn globale Importe sich gegenseitig behindern

[4:50 - 5:14] Der ganze Sinn von Namespaces ist es, Typen mit demselben kurzen Namen vor Kollisionen zu bewahren. Das globale Importieren eines Namensraums entfernt diese Puffer für das gesamte Projekt auf einmal. Wenn Ihr GlobalUsings.Data-Namespace eine Datenklasse enthält und Sie auch global System.Data importieren, muss jede Datei nun unterscheiden. Die Kosten zeigen sich nicht dort, wo der Konflikt auftritt, sondern in jeder zukünftigen Datei, die zwischen den beiden gefangen ist.

Tims Anleitung ist es, globale usings bewusst zu verwenden, Namespaces zu bevorzugen, von denen Sie wissen, dass das Projekt universell abhängt, und besonders vorsichtig mit global using static zu sein. Ein vernünftiger Anfangssatz sind die Namespaces, die jede Datei ohnehin importiert; das Wachsen der Liste darüber hinaus erfordert eine Codeüberprüfung.

Abschließendes Fazit: Weniger Zeremonie, gleiches Verhalten

[5:14 - 5:33] Die globalen usings sind eine kleine Funktion, die sich über die gesamte Lebensdauer eines Projektes auszahlt. Jede Datei, die nicht mehr fünf Zeilen redundanter Importe enthält, ist eine Datei, die schneller zum eigentlichen Code öffnet, und eine Bearbeitung eines gemeinsam genutzten Namensraums erfolgt an einem Ort statt an Dutzenden. Die gleiche Sorgfalt, die in Typ-Aliase und die breitere using-Familie einfließt, gilt auch hier: Setzen Sie es dort ein, wo der Lesbarkeitsgewinn klar ist, und halten Sie die zentrale Datei klein genug, dass der nächste Entwickler sie mit einem Blick erfassen kann.

Abschluss

[5:14 - 5:33] Globale usings ersetzen dateienspezifische using-Zeilen durch projektweite Direktiven, die globale using-static-Variante lässt das Klassenpräfix bei statischen Mitgliedsaufrufen aus, und eine einzige Usings.cs-Datei im Projektstamm ist die Konvention, die die Auffindbarkeit gewährleistet. Das Feature ist opt-in und additiv, sodass die Einführung in eine bestehende Codebasis inkrementell erfolgt.

Beispiel-Tipp: Wenn Sie implizite Usings über <ImplicitUsings>enable</ImplicitUsings> in Ihrem .csproj aktivieren, fügt das SDK automatisch eine kuratierte Menge globaler Usings hinzu (wie System, System.Linq und System.Collections.Generic), ohne dass Sie diese schreiben müssen. Kombinieren Sie dies mit Ihrer eigenen Usings.cs für projektspezifische Importe, und der Anfang jeder Datei wird deutlich kürzer.

Schauen Sie sich das vollständige Video auf seinem YouTube-Kanal an und gewinnen Sie weitere Einsichten über moderne C#-Projektstrukturen in der 10-Minuten-Trainingsreihe.