Startseite>ASP-Quellcode>Andere Kategorien
Herunterladen

Stark typisierte Client-Web-API-Generatoren generieren Client-API-Codes in C# und TypeScript direkt aus der ASP.NET (Core)-Web-API, ohne Swagger/OpenAPI oder Swashbuckle einzubeziehen, und maximieren so die Unterstützung für Datentypen Ihres Code First-Ansatzes der ASP.NET-Web-API .

Produkte

Dieses Projekt liefert diese Produkte:

  1. Codegenerator für stark typisierte Client-API in C#, der .NET und Xamarin.Forms unterstützt.
  2. Codegeneratoren für stark typisierte Client-APIs in TypeScript für jQuery, Angular 2+, Aurelia, Axios und Fetch API.
  3. TypeScript CodeDOM, eine .NET CodeDOM-Komponente für TypeScript zur Entwicklung von TypeScript-Codegeneratoren.
  4. POCO2TS.exe, ein Befehlszeilenprogramm, das TypeScript-Schnittstellen aus POCO-Klassen generiert.
  5. Fonlow.Poco2Ts, eine Komponente, die TypeScript-Schnittstellen aus POCO-Klassen generiert.
  6. Plugins für jQuery, AXIOS, Fetch API, Aurelia, Angular 2+ sowie Angular Typed Reactive Forms.
  7. Fonlow.DataOnlyExtensions mit JSON-Konvertern zur Handhabung von Nur-Datum-Szenarien zwischen Clients und Servern, die sich in unterschiedlichen Zeitzonen befinden. Ein .NET Framework-Paket ist ebenfalls verfügbar.

Pakete

Anwendungsfälle und Downloads

Die Produkte werden größtenteils über NuGet veröffentlicht.

  1. Generieren Sie die C#-Client-API und verwenden Sie dann das Paket Fonlow.WebApiClientGenCore
  2. Generieren Sie die TypeScript-Client-API und verwenden Sie dann eines der Plugins von Fonlow.WebApiClientGenCore:
    1. jQuery- und HttpClient-Hilfsbibliothek
    2. Eckig 6+
    3. Angular 6+, plus FormGroup-Erstellung für reaktive Formulare mit Beschreibung
    4. AXIOS
    5. Aurelia
    6. API abrufen
  3. Entwickeln Sie den TypeScript-Codegenerator mithilfe des CodeDOM-Ansatzes und verwenden Sie dann das Paket Fonlow.TypeScriptCodeDOMCore.
  4. Entwickeln Sie den TypeScript-Codegenerator über den CodeDOM-Ansatz für POCO und mehr und verwenden Sie dann das Paket Fonlow.Poco2TSCore oder PowerShell 7-Skripte.
  5. Generieren Sie Schnittstellen vom Typ TypeScript und verwenden Sie dann Poco2TSCore.exe, eine Konsolen-App.
  6. Entwickeln Sie eine Funktion, die das XML-Dokument einer .NET-Assembly liest, und verwenden Sie dann das Paket Fonlow.DocCommentCore.

Hinweise:

  • OpenApiClientGen basiert auf Schlüsselkomponenten von WebApiClientGen und ist ein Spin-off zur Generierung von Client-API-Codes in C# und TypeScript gemäß einer Definitionsdatei der Swagger/Open API Specification.
  • WebApiClientGen verwendet keine Swagger-/OpenAPI-Definitionen, sondern generiert Codes aus Laufzeittypinformationen einer laufenden Web-API des Debug-Builds und beseitigt so die inhärenten Einschränkungen von OpenAPI gegenüber .NET-Typen und der Web-API, um ASP eine bessere Entwicklererfahrung zu bieten. NET (Core) Web-API-Entwickler.

Bemerkungen:

  • Die Entwicklung begann im Jahr 2015 mit der Unterstützung von .NET Framework und dann von .NET Core 2. Das Tag „LastCore31“ soll den letzten Snapshot markieren, der .NET Framework 4.6.2 und .NET Core 3.1 unterstützt.
  • Ab dem 10.02.2021 wird die Entwicklung nur noch .NET 5 und höher unterstützen.
  • Wiki-Inhalte zum .NET Framework werden in absehbarer Zukunft aufbewahrt.

Hauptmerkmale

  1. Generierte Client-API-Codes werden direkt von den Web-API-Controller-Methoden, .NET-Primitivtypen und POCO-Klassen zugeordnet. Dies ähnelt dem, was svcutil.exe in WCF angeboten hat.
  2. Dokumentkommentare von Controller-Methoden und POCO-Klassen werden kopiert.
  3. Einige Validierungsattribute werden zum Generieren von Dokumentkommentaren für TypeScript-Codes verwendet.

Hauptvorteile für die Entwicklererfahrung

  1. WebApiClientGen ist nahtlos in die ASP.NET Core-Web-API integriert und erfordert nur sehr geringe Schritte/Aufwände für die Einrichtung, Wartung und Synchronisierung zwischen Web-API und Client-APIs während der RAD- oder agilen Softwareentwicklung.
  2. Unterstützt alle primitiven .NET-Typen, einschließlich Dezimalzahlen.
  3. Unterstützt DataTime, DataTimeOffset, DateOnly, Array, Tuple, Dynamic Object, Dictionary und KeyValuePair
  4. Stark typisierte generierte Codes unterliegen der Typprüfung zur Entwurfszeit und zur Typprüfung zur Kompilierungszeit.
  5. Bieten Sie ein hohes Maß an Abstraktion und schützen Sie Anwendungsentwickler vor sich wiederholenden technischen Details von RESTful-Praktiken und herkömmlichen Codes von AJAX-Aufrufen.
  6. Umfangreiche Metainformationen einschließlich Dokumentkommentaren machen IDE Intellisense hilfreicher, sodass Anwendungsentwickler weniger separate API-Dokumente lesen müssen.
  7. Generierte Dokumentkommentare basierend auf .NET-Validierungsattributen.
  8. Generierte Dokumentkommentare basierend auf numerischen Typen, DateOnly und GUID für TypeScript-Codes.
  9. Generierte TypeScript-Codes entsprechen dem strikten TypeScript-Modus und die generierten Angular 2+-Codes entsprechen dem strikten Angular-Modus.

Beispiele

  1. POCO-Kurse
  2. Web-API
  3. Generierte Client-API-C#-Codes
  4. Client-Codes, die die generierte Bibliothek in C# verwenden
  5. Generierte Client-Datenmodelle und API in TypeScript für jQuery, für Angular 2, für Aurelia und für Axios
  6. Client-Codes unter Verwendung der generierten Bibliothek in TypeScript
  7. Online-Demo mit Angular Heroes, gehostet in GitHub.IO, im Gespräch mit einem echten Backend

Bemerkungen:

  1. JavaScript-Codes, die aus generierten TypeScript-Codes kompiliert wurden, könnten in JS-Anwendungen verwendet werden. Offensichtlich sind jedoch keine Typinformationen verfügbar, während Anwendungsprogrammierer weiterhin Intellisense und Abstraktion von AJAX-Details genießen können.
    1. React- und Vue.js-Anwendungen verwenden normalerweise Axios oder Fetch API für HTTP-Anfragen. Seit Juni 2019 unterstützt babel dank dieser Pull-Anfrage Namespaces, sodass Sie in der Lage sein sollten, React TSX-Programmierung mit generierten TypeScript-Codes durchzuführen.

Konzepte

  1. Web-API-Anbieter/-Entwickler sollten Entwicklern von Client-Programmen Client-API-Bibliotheken zur Verfügung stellen, wie dies Google, Amazon usw. tun würden, damit die RESTful-Web-API breitere Verbraucher (intern und extern) effizient erreichen kann.
  2. Für Client-Entwickler sind klassische Funktionsprototypen wie ReturnType DoSomething(Type1 t1, Type2 t2 ...) die API-Funktion und der Rest sind die technischen Implementierungsdetails des Transports: TCP/IP, HTTP, SOAP, ressourcenorientiert, CRUD- basierte URIs, RESTful, XML und JSON usw. Der Funktionsprototyp und ein Teil des API-Dokuments sollten gut genug sein, um die API-Funktion aufzurufen.
  3. Je besser Sie die Interessenstrennung in Ihrem Web-API-Design vornehmen, desto mehr profitieren Sie von den Komponenten dieses Projekts, um schneller Geschäftswerte zu liefern, mit weniger handgefertigten Codes, weniger sich wiederholenden Aufgaben und geringerer Wahrscheinlichkeit menschlicher Fehler.

Erwartete Programmierpraktiken

Stark typisierter Funktionsprototyp

ReturnType DoSomething(Type1 t1, Type2 t2 ...)

		[ HttpGet ]
		[ Route ( "getPerson/{id}" ) ]
		public Person GetPerson ( long id )

Modellvalidierung durch Middleware

Anstatt explizite Codes zur Validierung der Anforderungsnutzlast zu schreiben, wird erwartet, dass Sie zur Validierung Middleware verwenden. Zum Beispiel: 

 public void ConfigureServices ( IServiceCollection services )
{
	services . AddControllers (
		options =>
		{
			options . Filters . Add ( new ValidateModelAttribute ( ) ) ; // wholesale style to check model binding for all API calls.

Referenzen:

  • Modellvalidierung in der ASP.NET-Web-API
  • Modellvalidierung in ASP.NET Core MVC und Razor Pages

Modellvalidierung durch ApiControllerAttribute

Zum Beispiel: 

	[ ApiController ]
	[ Route ( "api/[controller]" ) ]
	public class HeroesController : ControllerBase
	{

Von Middleware verarbeitete Nicht-2xx-HTTP-Statuscodes, optional

Selbst wenn Sie in einer API-Funktion explizit Codes schreiben, um Ausnahmen zu behandeln und Nicht-2xx-HTTP-Statuscodes zurückzugeben, sollten Sie über ein sicheres Netz zum Abfangen nicht abgefangener Ausnahmen und zur Rückgabe von HTTP-Statuscodes verfügen.

Referenzen:

  • ASP.NET Core-Middleware

Voraussetzungen

Serverseite:

  1. .NET 7/8
  2. CodeGenController hinzufügen.
  3. Fügen Sie in den Dienststartcodes Folgendes hinzu: 
 services . AddControllers (
	options =>
	{
#if DEBUG
		options . Conventions . Add ( new Fonlow . CodeDom . Web . ApiExplorerVisibilityEnabledConvention ( ) ) ;
#endif
	}
)

Bemerkungen:

  • Microsoft veröffentlicht seit 2016 jedes Jahr ein großes Upgrade von .NET (Core), die Bibliotheken in diesem Repository werden im Allgemeinen spätestens etwa ein halbes Jahr später folgen.
  • Die öffentlichen Bibliotheken sind mit .NET eine Version hinter der neuesten Version, während die ASP.NET-Demo-App und die Integrationstestsuiten mit generierter .NET-Client-API mit der aktuellen Version von .NET ausgestattet sind.

.NET-Clientseite:

  1. .NET Framework 4.5.2 oder Universal Windows oder Mono.Android oder Xamarin.iOS oder .NET Core 2.0/2.1/3 und .NET 5
  2. ASP.NET Web API 2.2-Clientbibliotheken
  3. Json.NET von Newtonsoft für Content-Type application/json
  4. Microsoft Build Tools 2015

NewtonSoft.Json oder System.Text.Json

Ab .NET 7 setzt System.Text.Json für die Serialisierung über 95 % von NewtonSoft.Json neu zusammen. Es gibt nur wenige Randfälle komplexer POCO-Strukturen, die System.Text.Json nicht verarbeiten kann.

WebApiClientGen unterstützt sowohl serverseitig als auch C#-clientseitig. Für C#-Clients können Sie „UseSystemTextJson“ in den Codegen-Einstellungen verwenden.

Wenn Ihre Anwendung jedoch komplexe POCO-Strukturen umfasst, ist die Verwendung von NewtonSoft.Json ab .NET 7 eine sichere Wahl.

TypeScript-Clientseite:

  1. TypeScript-Compiler
  2. jQuery
  3. Winkel 2-17
  4. Aurelia
  5. Axios
  6. API abrufen

Weitere Einzelheiten finden Sie unter:

  1. WIKI
  2. Einstellungen erklärt
  3. Generieren Sie die C# .NET-Client-API für die ASP.NET-Web-API
  4. Generieren Sie die TypeScript-Client-API für die ASP.NET-Web-API
  5. ASP.NET-Web-API, Angular2, TypeScript und WebApiClientGen
  6. Generieren Sie die C#-Client-API für die ASP.NET Core-Web-API
  7. Vorgesehene Lösungen für absichtliche Einschränkungen stark typisierter OpenAPI-Client-Generatoren. Der Artikel verwendet OpenApiClientGen lediglich als Beispiel, während die Prinzipien und Lösungen auf von WebApiClientGen generierte Codes für Ihre Client-Apps angewendet werden können.
  8. DateOnly in ASP.NET Core 6

Demoanwendungen

Die Demoanwendungen in diesem Repository dienen hauptsächlich dem Testen von WebApiClientGen während der Entwicklung. Und es gibt weitere Demoanwendungen in den folgenden Repositorys, die demonstrieren, wie reale Anwendungen WebApiClientGen nutzen könnten:

  1. WebApiClientGen-Beispiele für .NET Framework, .NET Standard, Xamarin und vue TS.
  2. .NET Core-Demo für ASP.NET Core MVC, Web API, ASP.NET Core + Angular, MAUI, fetchAPI, vue TS und React TS.
  3. WebApiClientGen vs. Swagger

Diese Demoanwendungen werden aktiv gepflegt und mit den neuesten Frameworks auf dem neuesten Stand gehalten. Wenn Sie noch bei einigen älteren Frameworks wie Angular 4 oder 5 oder .NET Core 2.0 bleiben, können Sie zu den entsprechenden Tags der Repositorys navigieren und zur Kasse gehen.

Tour der Helden

Tour of Heroes ist die offizielle Angular-Tutorial-Demo-App.

Um die Programmiererfahrung bei der Verwendung von WebApiClientGen zu veranschaulichen, wurden die folgenden Demo-Apps mit einem ähnlichen Architekturdesign für die gleichen Funktionsmerkmale auf verschiedenen Entwicklungsframeworks oder Bibliotheken erstellt, jedoch mit einem echten Backend.

  1. Angular 2+ und typisierte reaktive Formen
  2. Xamarin
  3. MAUI. Von Xamarin Heroes migriert.
  4. Aurelia. Integrationstestsuite enthalten.
  5. Reagieren. Integrationstestsuite enthalten.
  6. Blazor Standalone

NewtonSoft.Json oder System.Text.Json

Obwohl WebApiClientGen beide unterstützt, hat sich die primäre Unterstützung seit 2024 auf System.Text.Json verlagert.

NewtonSoft.Json bietet in bestimmten Szenarien und Kontexten dennoch einige Vorteile:

  1. Wenn Sie viele POCO-Klassen mit DataContractAttributes versehen haben, weil Sie ältere Apps unterstützen oder sowohl XML- als auch JSON-Serialisierung unterstützen, bietet Ihnen NewtonSoft.Json inhärente Unterstützung, während System.Text.Json seit .NET 7 einige problematische und indirekte Unterstützung bietet.
  2. Für einige Array-Typen und Dynamik ist NewtonSoft.Json immer noch besser.
Expandieren
Zusätzliche Informationen
Ähnliche Anwendungen
Empfohlen für Sie
Ähnliche Nachrichten Alle