SnailAspNetCoreFramework

Projekteinführung

• Dieses Projekt ist als schnelles Entwicklungsframework für kleine und mittlere Unternehmen positioniert, das auf dem asp.net-Kern basiert, einschließlich vollständigem Back-End- und Front-End-Code.
• Die Version v2.0 befindet sich derzeit in der Entwicklung. Die Version v1.0 kann direkt nach dem Wechsel im Zweig ausgeführt werden. Anleitungen finden Sie in meiner Blogreihe oder in den Dokumenten im Projekt.
• Back-End-Technologie-Stack: asp.net core 3.1, cap, swag, ef core code first, autofac, automapper, nlog, aop
• Front-End-Technologie-Stack: vue-element-admin, grobe Komponenten des Rapid-Development-Moduls, Mock
• Implementierte Funktionen: rollenbasierte Berechtigungskontrolle, Projekthierarchievereinbarung, automatische Codegenerierung, Protokollierung, Leistungsüberwachung, AOP usw.

So führen Sie das Projekt aus

 git clone [email protected]:shengyu-kmust/SnailAspNetCoreFramework.git
git clone [email protected]:shengyu-kmust/Snail.git
cd SnailAspNetCoreFramework
dotnet build

Projektdemonstration

Das Folgende ist ein Demonstrationsdiagramm basierend auf der Version v1.0

• 1. Laden Sie das Projekt herunter und führen Sie es aus
• 2. Generieren Sie automatisch Projekte basierend auf Konfigurationsdateien
• 3. Führen Sie das Projekt aus

Einführung in das Projektverzeichnis

--ApplicationCore // Die Kernabstraktionsschicht übernimmt den klaren Architekturmodus und ist nicht von anderen Schichten abhängig. Die anderen drei Projekte basieren alle auf dieser Art von Bibliothek und sind für öffentliche Definitionen wie Schnittstellen, Konstanten, Aufzählungen, DTO, Entitäten usw. verantwortlich. usw.
----Const // Konstantendefinition, z. B. Konfigurationskonstanten, Ereignisnamenkonstanten
----Dtos // alle Dtos
----Entities // Alle Entitäten
----Enums // Aufzählung
----IServices //Abstrakte Definition der Serviceschicht
----Dienstprogramme // Hilfeklasse

--Infrastructure // Die Infrastrukturschicht stellt Datendienste für die oberen Schichten bereit (z. B. Serviceschicht und Anwendungsschicht).
----Data/config // Fluent-API-Konfiguration des Datenbank-EntityFrameworks
----EFValueConverter // Konvertierung zwischen Entityframework-Datenbanktyp und Clr-Typ, z. B. Aufzählungskonvertierung
----Migrations //Erstellen Sie zuerst ein Verzeichnis für die Migration des EntityFramework-Codes

--Service // Serviceschicht, wird zur Implementierung der Serviceschnittstelle in ApplicationCore verwendet, der Hauptschicht für die Implementierung der Anwendungslogik
----Cache // Cache-Implementierung, die später entfernt und in das Snail-Projekt extrahiert wird.
----Interceptor //Interceptor standardmäßig implementiert
----BaseService.cs // Die Basisklasse jedes Dienstes enthält die gemeinsamen Methoden jedes Dienstes, z. B. CRUD
----InitDatabaseService.cs // Verantwortlich für die Initialisierung der Datenbankdaten
----InterceptorService.cs //Interceptor-Basisklasse

--Web // Verantwortlich für die gesamte Verarbeitung der Eingabe und Ausgabe von Schnittstellenparametern (z. B. Parameterüberprüfung, Reservierung des Ausgabeformats usw.)
----AutoFacModule // Autofac-Injection-Konfiguration
----AutoMapperProfiles // Automapper-Konfiguration
----ClientApp // Frontend-Projekt
------build // Ausgabeverzeichnis, das durch die Front-End-Kompilierung generiert wird
------mock // Front-End-Mock
------src // Front-End-Kerncode
----CodeGenerater //T4-Modul und zugehörige Logik zur Codegenerierung
----ConfigureServicesExtensions // ServiceProvider-Injection-Erweiterungen, um zu vermeiden, dass sie in die Startdatei geschrieben werden
----Controller //Controller
----docs // Dokumentensatz
----Dto // Die DTO-Klasse wird nur in der Webebene verwendet
----Filter // filtern
----Hubs // signalr
----Permission //Standardimplementierung von Berechtigungen
----staticFile // Wird zum Speichern hochgeladener Dateien verwendet

Gesamtkonstruktionsentwurf des Projekts

DDD wird verwendet, es müssen jedoch je nach Größe des Projekts unterschiedliche DDD-Technologien angewendet werden. Im Allgemeinen ist es in die folgenden Projekte unterteilt

• Service: Serviceschicht, die zur Implementierung der Serviceschnittstelle in ApplicationCore verwendet wird, der Hauptschicht für die Implementierung der Anwendungslogik
• Infrastrukturschicht: Basisschicht. Diese Schicht wird in verschiedenen Projekten wiederverwendet. Sie basiert auf der Schnittstellenkonvention der ApplicationCore-Schicht, um Datendienste für die oberen Schichten (z. B. die Serviceschicht und die Anwendungsschicht) bereitzustellen. Gleichzeitig wird die universelle Datenzugriffsschnittstelle von IDAL implementiert.
• ApplicationCore-Schicht: Anwendungslogikschicht, DDD-Modus, enthält die gesamte Geschäftslogik und ist nicht von anderen Schichten abhängig
• Webschicht: Verantwortlich für die gesamte damit verbundene Verarbeitung der Eingabe und Ausgabe von Schnittstellenparametern (z. B. Parameterüberprüfung, Ausgabeformatreservierung usw.) und Aufrufe an die Anwendungs-/DAL-Schicht.

Universelle Datenberechtigungen und -überprüfung

WEB-Schicht

• Verantwortlich für die Verarbeitung von Eingabe- und Ausgabeparametern, das Abfangen von Ausnahmen und das Web-Caching
• Für Datenoperationen vom Typ Abfragestatistik kann die DAL-Schicht direkt aufgerufen werden.
• Die Konfiguration von Entwicklungs- und Testumgebungen kann getrennt werden

Parameterüberprüfung – implementiert

• Verwendung der Microsoft-Schnittstelle --implementiert

Ausgabekonvention – implementiert

• Der HTTP-Statuscode folgt der Statuscode-Konvention: 20x ist Erfolg (die Schnittstelle wurde erfolgreich aufgerufen), 40x ist ein Anforderungsfehler (Geschäftsausnahme, nicht autorisiert usw.), 50x ist ein Serverfehler (Serverausnahme) – implementiert
• Der zurückgegebene Ergebnisinhalt liegt hauptsächlich im tatsächlichen Datenformat vor, das vom Frontend benötigt wird. Bei diesem handelt es sich um ein JSON-Objekt. Wenn es sich um eine Fehlermeldung handelt, wird der Fehlerinhalt zurückgegeben. --Erreicht

Ausnahmebehandlung – implementiert

• Die Ausnahmebehandlung nutzt Microsoft-Technologie, siehe https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/error-handling?view=aspnetcore-2.2
• Alle Ausnahmen werden nicht abgefangen
• Geschäftsausnahmen werden nach außen weitergeleitet. Serverausnahmen werden abgefangen und nach außen weitergeleitet. Das Ausgabeformat der Eingabeaufforderung folgt der Ausgabekonvention.

Prahlerei – implementiert

• Verwenden Sie NSwagger

ApplicationCore-Schicht

• Dieses Projekt ist nicht von anderen Projekten abhängig. Verwenden Sie eine saubere Architektur. Weitere Informationen finden Sie unter: https://docs.microsoft.com/zh-cn/dotnet/standard/modern-web-apps-azure-architecture/common-web- Anwendungsarchitekturen

Cache

• Die ICache-Schnittstelle implementiert Redis, Memcached, MemoryCache usw. Sie können die Verwendung von Easycaching in Betracht ziehen.
• Verwenden Sie AOP zum Caching, um zu vermeiden, dass in jeder Methode Caching-Logik geschrieben wird. easycaching+autofac
• Cache-Updates erfolgen ereignisgesteuert und es werden Komponenten von Drittanbietern eingeführt. easycaching+cap

Domänengesteuert

Domänengesteuert: Wenn es von anderen Schichten abhängt, hängt es von der Schnittstelle der entsprechenden Schicht und nicht von der Implementierung ab.

AOP – implementiert

• Für den AOP-Eintrag in Protokolle und Caches sollten Sie die Verwendung von Autofac in Betracht ziehen

IOC – implementiert

• Verwenden Sie Autofac

Speichertabelle – implementiert

• Speichern Sie Tabellen, die sich selten ändern und relativ kleine Datenmengen im Speicher haben (keine Caches, sondern Objekte), und verwenden Sie ereignisgesteuertes Denken, um die neuesten Daten zu synchronisieren.

Ereignis

• veröffentlichen und abonnieren
• Verwenden Sie cap, um zwischen verteilten und einzelnen Anwendungen zu wechseln

Protokollverarbeitung – implementiert

• Verwenden Sie nlog

Befehlsbus --implementiert

• Verwenden Sie Mediatr

DAL-Schicht

• Verantwortlich für alle datenbezogenen Vorgänge
• Kapseln Sie allgemeine Datenzugriffsschnittstellen und -implementierungen, z. B. die Verwendung von EF zum Implementieren der folgenden Funktionen
• Nutzen Sie die Idee der schnittstellenorientierten Programmierung, um die DAL-Schicht künftig mit anderen Technologien als EF zu erweitern.
• Bei Verwendung des Repository-Modus ist EF selbst tatsächlich ein Repository-Modus. Um jedoch das Abfangen und Anwenden seiner eigenen Logik auf der Ebene von Datenbankzugriffsvorgängen zu vereinheitlichen, verwendet es dann sein eigenes Repository, um EF zu kapseln
• Einzeltabellenabfrage, Paging
• Einfache relationale Abfrage mehrerer Tabellen, Paging
• Einfaches CRUD

Automapper

• Referenz-Automapper für Objektzuweisung und -konvertierung
• Implementieren Sie die ausdrucksbasierte Objectmapper-Klasse für eine einfache Objektzuweisung und gleichen Sie die Mängel der komplexen Konfiguration und der geringen Leistung des Automappers mithilfe von Reflektion aus.

Verwendung von EF

• EF-Ausführungs-SQL-Sprachprotokoll** – implementiert**
• Verwenden Sie für Aufzählungstypen die ValueConverter-Technologie von EF zur automatischen Konvertierung. Es wird vereinbart, dass der in der Datenbank gespeicherte Typ ein String-Typ und kein Int-Typ ist, was für das Verständnis hilfreich ist. ** - Implementiert **

Echtzeit-Messaging

• Verwenden Sie signalr

Technologieauswahl

Transaktionsverarbeitung

Verwenden Sie die Modi „Repository“ und „Unit of Work“, aber verwenden Sie den mit EF gelieferten Repository-Modus.

Datenbankverarbeitungsmethode

• Verwenden Sie EF für die Datenverarbeitung und ziehen Sie keine anderen Methoden in Betracht.

Front-End-Schnittstelle

• Fügen Sie es in das Webprojekt ein und verwenden Sie die Spa-Methode

tun müssen

• Unit-Test-Injektion
• Die Serviceschicht sollte nicht in der Webschicht, sondern im Anwendungskern liegen

mehrsprachig

Diverse technische Details

KAPPE

• Die ursprüngliche Implementierung von CAP unterstützt Autofac nicht sehr gut. In diesem Projekt wurde SnailCapConsumerServiceSelector dafür geschrieben.
• CAP behandelt Controller und Nicht-Controller nativ unterschiedlich. Controller müssen der Methode lediglich das CapSubscribe-Attribut hinzufügen, während Controller die ICapSubscribe-Schnittstelle in der Klasse implementieren und der Methode das CapSubscribe-Attribut hinzufügen müssen.

Wie zu verwenden

1. git clone dieses Projekt 2. Konfigurieren Sie codeGenerate.json 3. Führen Sie dieses Projekt aus und führen Sie nach der Anmeldung bei swagger die codeGenerate-Schnittstelle aus 4. Führen Sie add-migration aus 5. Starten Sie das Projekt

Tutorial-Blogbeitrag

SnailAspNetCoreFramework Framework Series Blog
1. Einführung und allgemeine Designideen für jedes Projekt und Verzeichnis innerhalb des Frameworks – SnailAspNetCoreFramework-Rapid-Development-Framework
2. Überprüfung der Schnittstelleneingabe, Ausgabeformat und Ausnahmebehandlung – Back-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
3. Universelles Berechtigungsdesign - Back-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
4. So stellen Sie gute Schnittstellendokumente (Swagger) für das Front-End bereit – SnailAspNetCoreFramework-Back-End-Design für das Rapid Development Framework
5. Cache-Nutzung in verschiedenen Szenarien – Backend-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
6. Castle-basiertes AOP-Design und gemeinsamer Cache, Leistung, Log-Interceptor-Implementierung – SnailAspNetCoreFramework-Back-End-Design für das Rapid Development Framework
7. Einführung in die Abhängigkeitsinjektion – Autofac – Back-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
8. Warum Eventbus verwenden und wie man es verwendet - Back-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
9. Einführung in Nlog, die Protokollkomponente – SnailAspNetCoreFramework-Back-End-Design für das Rapid Development Framework
10.Mediatr-Einführung - SnailAspNetCoreFramework-Back-End-Design für das Rapid Development Framework
11. Universelles CRUD-Design für Controller-, Service- und Dal-Schichten – Backend-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
12. Objektzuordnungstool Automapper - SnailAspNetCoreFramework-Back-End-Design für das Rapid Development Framework
13. So überwachen Sie die von EF generierten SQL-Anweisungen – Back-End-Design des SnailAspNetCoreFramework Rapid Development Framework
14. Einführung in verschiedene Bereitstellungsmethoden von .net Core – SnailAspNetCoreFramework-Back-End-Design für das Rapid Development Framework
15. Echtzeit-Kommunikationssignal - SnailAspNetCoreFramework-Back-End-Design für ein schnelles Entwicklungsframework
16. So verwenden Sie zuerst EF-Code, um die Datenbankversion des Projekts kontinuierlich zu iterieren – SnailAspNetCoreFramework-Back-End-Design für das Rapid Development Framework
17. Einführung in die automatische Codegenerierungsfunktion – SnailAspNetCoreFramework Rapid Development Framework Back-End-Design
18. So überwachen Sie, ob jede Funktion des Projekts normal ist (HealthCheck) - Back-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
19. Einführung in Hangfire für geplante Aufgaben – Backend-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
20. Allgemeine Einführung in das Front-End – Front-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
21. Kein Betteln mehr um Back-End-Schnittstellen (Verwendung von MOCK) – Front-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
22. Front-End-Berechtigungskontrolle – Front-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
23. So vermeiden Sie das wiederholte Schreiben von Front-End-CRUD-Code (Einführung und Verwendung verschiedener SnailXXX-Komponenten im Front-End) - Front-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks
24. Einführung in den Anforderungs-Proxy – Front-End-Design des SnailAspNetCoreFramework-Rapid-Development-Frameworks