هل من الممارسات السيئة أن يكون لطبقة الخدمة طرقًا لا تتعامل مع قاعدة البيانات؟

Question

لدي الطرق التالية في خدمة المستخدم الخاصة بي

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

ستلاحظ أن هناك بعض الطرق التي لا تتعامل مع قاعدة البيانات ، لكنني شعرت أن هذا كان مكانًا جيدًا لاستخدامها.

هل هذه ممارسة سيئة؟

ملاحظة: تتعامل طبقة المستودع الخاص بي بدقة مع قاعدة البيانات. يذهب تدفق بلدي.

قاعدة البيانات> LINQ (DBML)> طبقة المستودع> طبقة الخدمة> وحدة التحكم (أو غيرها).

Answer 1

مثال على رؤية ، يبدو وكأنه ممارسة سيئة. إذا رأيت جميع المعلومات التي تطرحها من طبقة الخدمة الخاصة بك متوفرة بالفعل على وحدة التحكم الخاصة بك نفسها. لماذا ترغب في عبور حدود التطبيق للحصول على هذه المعلومات؟

ومع ذلك ، قد يكون هناك سبب وجيه لإجراء عملية على طبقة الخدمة التي لا تتعامل بالضبط مع DB.

في حالتك ، أود أن أقول لاستخدام فئة مساعد من شيء من هذا القبيل في وحدة التحكم.

Answer 2

predeep لديه نقطة. لا تضع الأساليب التي تنتمي إلى WebProject في طبقة الخدمة. أنت فقط تضيف تبعية أخرى.

ليس من المفترض أن تكون طبقة الخدمة مجرد طبقة أعلى طبقة المستودع. يمكن أن يحتوي على منطق تعديل المعلومات من قاعدة البيانات أو أي مصدر بيانات آخر. من الجيد تمامًا إضافة طرق أخرى لا تضطر إلى فعل أي شيء مع قاعدة البيانات. هذا ما هي الطبقة. وإلا يمكنك فقط تخطي تلك الطبقة.