Ist es schlechte Praxis für die Service-Layer-Verfahren zu haben, die nicht mit der Datenbank umgehen?
-
28-09-2019 - |
Frage
Ich habe die folgenden Methoden in meinem User Service bekam
Public Interface IUserService
Sub AddUser(ByVal claimedidentifier As String, ByVal notes As String)
Function GetAllUsers() As IList(Of User)
Function GetUserByID(ByVal id As Integer) As User
Sub UpdateUser(ByVal user As User)
Sub SubmitChanges()
''# Below are methods that do not require database calls.
Function GetUserIPAddress() As String
Function GetUserBrowser() As String
Function GetUserOperatingSystem() As String
Function GetUserSubDomain() As String
End Interface
Sie werden feststellen, dass es ein paar Methoden, die mit der Datenbank nicht viel, aber ich fühlte, dass dies ein guter Ort war, sie zu benutzen.
Ist dies als schlechte Praxis?
Hinweis: meine Repository-Schicht befasst sich ausschließlich mit der Datenbank. Mein Flow geht.
Datenbank> LINQ (DBML)> Repository-Schicht> Service Layer> Controller (oder andere).
Lösung
Beispiel, dass Sie gesichtet haben, so scheint es wie eine schlechte Praxis. Wenn Sie alle Informationen sehen, dass Sie von Ihrem Service-Layer fragen ist eigentlich auf dem Controller selbst zur Verfügung. Warum möchten Sie anwendungsübergreifende Grenze, um diese Informationen zu erhalten?
Allerdings könnte es ein triftiger Grund sein, eine Operation auf Dienstschicht zu haben, die nicht exakt mit der DB zu tun.
In Ihrem Fall würde ich sagen, eine Hilfsklasse von etwas wie die in der Steuerung zu verwenden.
Andere Tipps
hat @Predeep einen Punkt. Legen Sie keine Methoden gehören, in dem Webprojekt in der Dienstschicht. Sie fügen einfach eine andere Abhängigkeit.
Die Service-Schicht soll nicht nur eine Schicht auf der Repository-Schicht. Es könnte Logik Modifizieren die Informationen aus der Datenbank oder einer anderen Datenquelle enthält. Es ist völlig in Ordnung, andere Methoden hinzufügen, die mit der Datenbank nichts tun müssen. Das ist, was die Schicht für. Sonst könnte man nur diese Schicht überspringt.