C# Web API - Ein vollständiger Blick auf die Strukturierung von APIs mit Derek Comartins Ansatz

Gemeinsame API-Strukturen im Blick

Derek beginnt mit der Frage, die sich die meisten Entwickler stellen, wenn sie ein neues Web-API-Projekt in Visual Studio erstellen:

"Wie sollten Sie Ihre HTTP-API strukturieren?"

Er erkennt sofort an, dass Web-API-Projekte auf viele Arten organisiert werden können. Zu den häufigsten Ordnerstrukturen, die Derek sieht:

• Gruppierung nach technischen Gesichtspunkten - Modelle werden in einen Models-Ordner, Controller in einen Controllers-Ordner und Services in Services eingeordnet.

• Verwendung von Clean Architecture oder Onion Architecture - wobei Projekte nach Schichten (API, Anwendung, Domäne, Infrastruktur) aufgeteilt werden, um Abhängigkeiten zu steuern.

• Kombination von Domain-Driven Design (DDD) mit vertikaler Slice-Architektur - Gruppierung von Endpunkten nach Merkmalen, aber immer noch mit domain-reichen Objekten.

Derek betont, dass mit jedem dieser Muster eine RESTful API erstellt werden kann, die die üblichen HTTP-Methoden (GET, POST, PUT, DELETE) für die Arbeit mit Ressourcen verwendet. Er warnt jedoch davor, zu viel in Ordnerstrukturen allein zu lesen:

Sie sehen vielleicht Entitäten, Aggregate oder Domänendienste, aber das bedeutet nicht, dass der Code wirklich domänenorientiertes Design betreibt - er verwendet diese Muster einfach

Beginnen Sie mit Einfachheit, nicht mit Komplexität

Derek sagt, sein Ziel sei ganz einfach:

Eines der wichtigsten Ziele, die ich mit dieser Struktur erreichen wollte, ist die Einfachheit

Anstatt sich in eine schwere Architektur im Stil von .NET Framework zu stürzen oder Muster aus Lehrbüchern zu wiederholen, wählt Derek ASP.NET Core Minimal APIs. Und warum? Denn sie erleichtern die Erstellung von APIs ohne den Overhead von Controllern und Boilerplate-Code.

Wenn Sie ein neues Web API-Projekt in Visual Studio oder sogar Visual Studio Code erstellen, beginnen Sie vielleicht mit dem Dialogfeld "Neues Projekt" und wählen ASP.NET Core Web API aus. Standardmäßig erhalten Sie Controller, Ordner und eine Menge Gerüste. Derek argumentiert, dass es oft besser ist, klein anzufangen - eine einfache, saubere Struktur.

Die Kernstruktur der Web-API von Derek

Derek stellt seine Webanwendungsstruktur mit .NET Core vor. Sie unterstützt gängige HTTP-Dienste und RESTful-APIs, über die verschiedene Softwareanwendungen miteinander kommunizieren können.

So gliedert er sein Web-API-Projekt:

• Endpunktdatei - Eine einzelne Datei, in der alle verfügbaren Routen in der API angezeigt werden. Anstatt sich durch mehrere Controller zu wühlen, möchte Derek einen schnellen Überblick über jede Get-Methode, Post-Methode, Put-Anfrage oder Delete-Anfrage, die die API unterstützt.

• Gemeinsamer Ordner - Enthält gemeinsamen Code wie Filter und Erweiterungen, die in verschiedenen Softwaresystemen verwendet werden.

• Feature-Ordner - Gemäß der vertikalen Slice-Philosophie erhält jede neue oder bestehende Ressource einen eigenen Ordner. Ein Posts-Ordner könnte zum Beispiel alles enthalten, was für GET /posts/{id}, POST /posts, PUT /posts/{id} und DELETE /posts/{id} benötigt wird.

• Datenordner - Enthält das Datenmodell und die Entity-Mappings. Hier könnte Entity Framework Core für eine nahtlose Datenbankintegration verwendet werden.

Durch die Gruppierung der Endpunkte nach Funktion vermeidet Derek, dass sich die Logik auf mehrere nicht miteinander verbundene Ordner verteilt.

Warum er Domain-Driven Design nicht erzwingt

Derek hat in der Vergangenheit Domain-Driven Design verwendet, aber in dieser C# Web API-Struktur trifft er eine wichtige Entscheidung:

"Wir werden kein domänenorientiertes Design verwenden."

Stattdessen lässt er "Daten einfach Daten sein" Seine Datenmodelle sind einfache Klassen mit einfachen Eigenschaften wie:

public class Post  
{  
    public int Id { get; set; }  
    public string Title { get; set; }  
}

public class Post  
{  
    public int Id { get; set; }  
    public string Title { get; set; }  
}

Es wird kein unnötiges Verhalten hineingepackt. Wenn Sie eine POST-Anforderung senden, um eine neue Ressource zu erstellen, speichert die API diese einfach. Wenn Sie eine DELETE-Anforderung mit einem id-Parameter senden, wird diese Ressource gelöscht.

Dieser Ansatz umfasst den architektonischen Stil des Representational State Transfer (REST), indem API-Endpunkte als Verben (get-Methode, post-Methode, put-Methode, delete-Methode) behandelt werden, die auf Ressourcen wie Post, User oder Comment wirken.

Schritt für Schritt durch die Lösung in Visual Studio

An dieser Stelle öffnet Derek seine Visual Studio-Lösung und führt uns durch das Programm:

• Die Endpoints-Datei listet jede Route auf - egal, ob es sich um eine GET-Anfrage handelt, die Daten abruft, eine POST-Anfrage, die eine neue Ressource hinzufügt, eine PUT-Anfrage, die Daten aktualisiert, oder eine DELETE-Methode, die eine vorhandene Ressource entfernt.

• Der Ordner Data enthält Mappings für Entitäten wie Post, User und Comment, die über Entity Framework mit einer Datenbank verbunden sind.

• Der Ordner Common enthält die gemeinsame Logik für HTTP-Dienste wie Validierungsfilter und Erweiterungen.

• Jeder Funktionsordner (Beiträge, Kommentare, Authentifizierung) enthält den gesamten für die jeweilige Ressource erforderlichen Code.

Dieses übersichtliche Projektordner-Layout verhindert, dass man sich durch einen übermäßig komplexen Projektdialog oder einen verstreuten Controller-Ordner wühlen muss.

Ein Endpunkt aufschlüsseln

Derek erklärt, dass jeder Endpunkt in seiner ASP.NET Core Web API eine in sich geschlossene Arbeitseinheit mit drei klaren Schritten ist:

1. Mapping - Definiert die HTTP-Methode und -Route. Eine Löschanforderung könnte zum Beispiel DELETE /posts/{id} auf eine Handler-Methode abbilden.

2. Anfrage- und Antwortverträge - Jeder Endpunkt hat seinen eigenen Anfragekörper und Antworttyp. Dadurch werden die HTTP-Dienste klarer und es wird vermieden, dass Schichten von doppelten DTOs entstehen.

3. Logik - Die eigentliche Handler-Methode, bei der die API Daten aus der Datenbank abruft, ein Datenmodell aktualisiert oder einen Statuscode wie return CreatedAtAction oder return NoContent zurückgibt.

Da Derek Minimal-APIs verwendet, sind diese Handler statische Methoden. Bei ASP.NET Core bedeutet dies, dass Sie Abhängigkeiten direkt einbinden können und keine sperrige Controller-Klasse benötigen.

Warum sich minimale APIs richtig anfühlen

Derek lobt Minimal APIs für ihre Einfachheit. Mit der minimalen Vorlage von ASP.NET Core können Sie ein Web-API-Projekt mit nur wenigen Zeilen in Program.cs beginnen:

var app = WebApplication.CreateBuilder(args).Build();

var app = WebApplication.CreateBuilder(args).Build();

Von dort aus fügen Sie Ihre Get-Methoden, Post-Methoden und Put-Anfragen auf einfache Weise hinzu.

Diese Einfachheit trägt dazu bei, Over-Engineering zu vermeiden - etwas, das Derek nur allzu oft sieht, wenn Entwickler blindlings NuGet-Paketvorlagen kopieren oder neue Controllerklassen für jeden kleinen Endpunkt erzwingen.

Wie sich Komplexität im Laufe der Zeit entwickeln kann

Derek nennt ein konkretes Beispiel: die Funktion "Gefällt mir ein Beitrag".

• Zunächst ist es ganz einfach: Prüfen Sie, ob ein Like vorhanden ist, und fügen Sie es hinzu, wenn nicht.

• Später muss die Softwareanwendung jedoch möglicherweise sofort einen Like-Zähler für Webseiten oder mobile Geräte zurückgeben.

• Zur Skalierung können Sie Daten denormalisieren, indem Sie dem Post-Datenmodell eine LikeCount-Eigenschaft hinzufügen.

Das bringt neue Herausforderungen mit sich:

• Jede Put- oder Delete-Methode, die sich auf likes auswirkt, muss die Anzahl korrekt aktualisieren.

• Wenn jemand einen ähnlichen Datensatz hinzufügt, ohne die API aufzurufen, ist die Zählung falsch.

Derek zeigt, dass man mit zunehmender Komplexität auch Muster wie:

• Repository-Muster zur Kapselung des Datenzugriffs.

• Aggregatwurzeln zur Behandlung von Verhaltensweisen (wie das Erhöhen von LikeCount).

• Outbox-Muster, um sicherzustellen, dass Ereignisse (wie "PostLiked") veröffentlicht werden.

Aber sein Hauptanliegen ist klar:

"Fangen Sie nicht hier an. Beginnen Sie mit einfachen Texten und entwickeln Sie diese nur bei Bedarf weiter."

Abschluss mit Dereks Fazit

Zum Schluss kehrt Derek zu seiner Hauptlektion für C# Web API-Entwickler zurück:

"Beginnen Sie mit einfach."

Wenn Sie ASP.NET Core Web API oder ASP.NET Web API in Visual Studio verwenden, ist es leicht, vom ersten Tag an ein Over-Engineering vorzunehmen und jeden Ordner, jedes Muster und jedes NuGet-Paket hinzuzufügen, das Sie je gesehen haben.

Aber Derek warnt: Wenden Sie Lösungen nicht blindlings an. Verstehen Sie die HTTP-Methoden, die Sie benötigen, die Daten, mit denen Sie arbeiten, und die Softwaresysteme, zwischen denen Sie die Kommunikation ermöglichen. Erstellen Sie Ihre RESTful-APIs Schritt für Schritt.

Für diejenigen, die Visual Studio Code oder eine andere integrierte Entwicklungsumgebung verwenden, gilt dieser Ratschlag ebenfalls: Egal, ob es sich um ein neues Projekt oder eine bestehende Ressource handelt, halten Sie Ihre Projektstruktur so einfach wie möglich und fügen Sie nur dann Muster hinzu, wenn die Komplexität der Realität dies erfordert.

Abschluss

Derek Comartins Video ist mehr als nur ein Leitfaden für die Erstellung einer C#-Web-API - es ist eine Erinnerung daran, dass gute Architektur mit Klarheit und nicht mit Unordnung beginnt. Anhand seiner realen ASP.NET Core-Web-API-Einrichtung in Visual Studio zeigt er, wie Minimal-APIs, Funktionsordner und unkomplizierte Datenmodelle die Grundlage für RESTful-APIs bilden können, die eine nahtlose Kommunikation zwischen verschiedenen Softwareanwendungen ermöglichen, ohne das Design zu sehr zu verkomplizieren.

Wenn Sie diesen Ansatz in Aktion sehen und Dereks Perspektive aus erster Hand erfahren möchten, ist sein Video eine hervorragende Ressource. Sein Channel ist mit ebenso aufschlussreichen Diskussionen über Softwaresysteme, Webservices und ASP.NET Core-Entwicklung gefüllt - ein Muss für jeden Entwickler, der sein Handwerk verbessern und seine Projekte sauber, praktisch und zukunftsfähig halten möchte.