Gestaltungsregeln für eine saubere Service-Architektur 20.07.2017, 00:00 Uhr

Gestaltungsregeln für eine saubere Service-Architektur: Klarheit am Server

Auf Grundlage von ASP.NET Boilerplate (ABP) soll ein Belegservice entstehen.
Angular2 ist da und Datenbindung am Web-Client setzt sich durch. Trotz TypeScript ist der Web-Client aber nicht der geeignete Ort für Business-Logik. Dazu ist er zu unsicher, ihm fehlen wichtige Informationen und zudem ist Client-Code nicht wiederverwertbar. Die Aufgabe, eine Server-Architektur zu entwerfen, die sich nicht früher oder später in Spaghetti-Code verwandelt, performant, sicher und übersichtlich ist, ist alles andere als trivial. Am Beispiel eines ERP-Belegs (im Code wird der Begriff Receipt für einen Beleg verwendet) sollen die wichtigsten Kernpunkte angesprochen werden, und um nicht auf der grünen Wiese beginnen zu müssen, soll ASP.NET Boilerplate [1] [2] als Grundlage dienen.
Im Grunde ist es einfach: Man schickt dem Server ein Data­transfer-Object (kurz DTO) oder man bekommt ein solches. Über Application-Services stellt der Server Adressen bereit, unter denen der Client ein DTO abrufen kann. Als Input für eine Service-Methode wird am besten auch ein DTO (die Konvention erwartet ein xxxInputDto) verwendet, so kann man die Methode erweitern, ohne die Signatur zu ändern.

dotnetpro

Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde
  • 2 Monate Gratis testen
  • Über 4.000 qualifizierte Fachartikel
  • Auf jedem Gerät verfügbar