| Zitat von kleinrechner |
|
Für jede Tabelle existiert ein entsprechender Service, zum Auslesen, Speichern usw der Daten in der Datenbank.
|
Was ist hier ein Service? Ein Implementierungspattern oder reden wir von Microservice?
Wenn es sich um ein Microservice im eigentlichen Sinne handelt, dann ist das eine Verletzung der Vorgehensweise, da sich zwei Microservices niemals die gleiche Datenbank teilen sollen.
Dank
Architektur mit Hirarchie und Berechtigung hab ich nun gesehen, dass Du von einer Implementierung sprichst.
Nein, ein Service ist ein Logik-Einheit und kennt den Datenbank-Aufbau nicht.
Es gibt daher nicht zwangweise für jede Tabelle einen Service.
Aber: es gibt für jede Tabelle ein Repository.
Dieses hat die Aufgabe von Lesen, Schreiben, Speichern. Das ist nicht Aufgabe vom Service.
Der Service sagt "wann" gespeichert wird (SaveChanges) aber nicht wie.
Wenn man Services zu klein schneidet, dann hilft das am Ende auch nicht.
| Zitat von kleinrechner |
|
Dies kann ich mithilfe von Navigations-Properties und EntityFramework über Include erreichen
|
Include braucht man gar nicht; damit lädst Du am Ende vom Tag viel zu viele Informationen, weil Du im aller aller seltestens Fall wirklich alle Entitäten in der vollen Breite brauchst.
Besser ist nur das zu laden, was Du brauchst, und das geht sehr einfach über Projektionen und gilt hier als Best Practise.
Eine Hilfestellung dazu bietet AutoMapper mit der ProjectTo Methode. Verwende ich auch in alle möglichen Konstellationen.
public Task<T?> GetAccountProjection<T>(int userId, CancellationToken ct) where T : class
=> QueryUsers(DbTrackingOptions.Disabled)
.Where(UserAccountQuery.HasId(id))
.ProjectTo<T?>(_mapper.ConfigurationProvider) <<<<<
.SingleOrDefaultAsync(ct);
UserEMailContactProjection? sender = await _userRepository
.GetAccountProjection<UserEMailContactProjection>(userId, ct).ConfigureAwaitFalse();
| Zitat von kleinrechner |
|
Welche Methode würdet ihr hier verwenden, was ist BestPractice? Ist die Service-Methode nicht deutlich langsamer?
|
Musst sagen, was die Service Methode ist. Ein Microservice soll man ja nicht direkt von Außen ansprechen, sondern über Gateways.
Ja, der Call auf ein Microservice ist i.d.R. langsamer als direkt auf die DB - aber das ist ein Nachteil, den man aufgrund der enormen Vorteile in Kauf nimmt.
Dein Service ist hier falsch implementiert, weil Du offenbar damit auch Datenbank-Operationen darstellst; weniger Logik.
Es ist absolut okay, wenn Du für lesende Operationen direkt auf das Repository zugreifst - aber lade nur die notwendigen Dinge. Anbei ein Bild wie der Zugriff durchaus erlaubt ist (siehe auch
[Artikel] Drei-Schichten-Architektur)
"Langsamer" ist hier aber eine Einheit, die vermutlich nicht im relevanten Bereich liegt.
