Soll ich einen AppService von einem anderen AppService aus anrufen?

Question

Kontext

derzeit in einem Dokument und Records Management-System arbeite ich (DRMS?). Aufgrund technischer Einschränkungen muss ich eine "view" -Datei und eine "source" -Datei (DOCX oder XLSX) speichern. Eine Ansichtsdatei ist eine PDF-Datei, die Benutzer für den täglichen Gebrauch drucken, herunterladen und anzeigen können, während eine Quelldatei die bearbeitbare Datei ist. Wenn Benutzer eine Datei aktualisieren müssen, laden sie die Quelle herunter, aktualisieren sie und laden eine neue Ansichtsdatei und die entsprechende Quelldatei hoch.

Ich kann derzeit keine XLSX-Viewer/Editoren implementieren, und aufgrund der Menge an Dateien kann ich nicht zu ODFs migrieren, um verfügbare Open-Source-Viewer zu verwenden.

Im Moment habe ich zwei Modelle wie folgt aus:

public class Document { 
    //Other fields 
    public virtual List<DigitalFile> Files { get; set; } 
} 

public class DigitalFile { 
    //Other fields 
    public virtual Document FileOf { get; set; } 
} 

Das Document Modell verfügt über alle „Geschäft“ Daten, während die DigitalFile Modelldaten über die Dateien hat sich (Pfad, URL, Typ, etc.)

Jedes Mal, wenn ein Dokument erstellt wird, enthält es 1 Ansichtsdatei (erforderlich) und möglicherweise 1 Quelldatei (einige Dokumente sind möglicherweise nicht editierbar). Von diesem können Sie wissen, dass wenn ein Dokument erstellt/aktualisiert wird mindestens 1 digitale Datei erstellt/aktualisiert wird.

Problem/Frage

werde ich ein DocumentAppService alle CRUD-Operationen zu handhaben, aber hier ist, wo meine Zweifel kommt, sollte ich eine AppService von einem anderen AppService anrufen? Ich meine, wenn ein Dokument erstellt wird, sollte die Create-Methode eine andere Create-Methode in DigitalFileAppService aufrufen? Oder sollte es besser sein, wenn DocumentAppService alles alleine behandelt?

Im Moment sind alle CRUD-Operationen auf DigitalFile an die Vorgänge in Document gebunden, weshalb ich Zweifel habe, ob ich einen AppService für die Dateien implementieren soll.

Answer 1

Ich empfehle nicht, einen Anwendungsdienst von einem anderen Dienst in der gleichen Domäne aufzurufen. Anwendungsdienste sind so konzipiert, dass sie von der UI-Ebene aus aufgerufen werden können. Es implementiert Audit-Protokollierung, Autorisierung, Validierung ... und sie werden wahrscheinlich nicht benötigt, wenn Sie einen Code in der gleichen Anwendungsebene verwenden.

Eine Anwendungsdienstmethode ist ein öffentlicher Endpunkt Ihrer Anwendung. Das Anrufen eines Anwendungsdienstes von einem anderen ist so, als würde man die Anwendung verlassen und von einem anderen Punkt aus eingeben. Wahrscheinlich möchten Sie auch keine Anwendungsdienstmethode ändern, wenn sich die Signatur einer anderen Anwendungsdienstmethode ändert (aufgrund einer Änderung der Anforderungen in der Benutzeroberfläche).

Mein Vorschlag ist, den geteilten Code in eine andere Klasse (wahrscheinlich ein Domain-Service) zu trennen und von beiden Anwendungsdiensten zu verwenden.

Answer 2

Die AppServices benötigt nicht mit Ihren Entitäten verwandt ist. Die AppServices können ein funktionaler Bedarf sein, so dass es einen UploadAppServices geben kann, wo zwei Entitäten erstellt werden.

Answer 3

Idealerweise sollte ein AppService nicht einen anderen AppService aufrufen.

Ein Anwendungsdienst sollte Datenübertragungsobjekte (DTOs) zu Domänenobjekten (Entitäten) zuordnen, Anwendungslogik anwenden und diese an die entsprechenden Domänenmanager zur Persistenz übergeben.

Es ist vollkommen in Ordnung, mehrere Manager zu injizieren, besonders wenn Mappings richtig konfiguriert sind. Wenn möglich, sollte ein Anwendungsdienst nicht von einem anderen Anwendungsdienst abhängig sein.

---

Realistisch gesehen, ein Anwendungsdienst kann durch die Annahme nested „sekundäre“ DTOs Bequemlichkeit (und Geschwindigkeit durch weniger Server Anrufe) bereitzustellen. Diese DTOs können eine separate Anwendungslogik beinhalten.

Eine Möglichkeit, dies sauber zu machen, besteht darin, internal Methoden im Abhängigkeitsanwendungsdienst zu erstellen, z. CreateInternal für eine Create Methode. Die Methoden internal werden nicht in die dynamischen Web-API-Methoden konvertiert und vermeiden Overhead der Autorisierung und Validierung durch Interzeptoren. Das ABP Framework bietet das Attribut [RemoteService(IsEnabled = false)] an, wenn Sie diese Methoden direkt von einem MVC-Controller aufrufen möchten.