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 Datatransfer-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