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.

Jetzt 1 Monat kostenlos testen!

Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
  • + Digitales Kundenkonto,
  • + Zugriff auf das digitale Heft,
  • + Zugang zum digitalen Heftarchiv,
  • + Auf Wunsch: Weekly Newsletter,
  • + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar