サービスレイヤーがデータベースを扱わないメソッドを持つことは悪い習慣ですか？

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にメソッドを入れないでください。別の依存関係を追加するだけです。

サービスレイヤーは、リポジトリレイヤーの上部にあるレイヤーであるとは思われません。データベースまたはその他のデータソースからの情報を変更するロジックが含まれている可能性があります。データベースで何もする必要がない他の方法を追加することはまったく問題ありません。それがレイヤーの目的です。それ以外の場合は、そのレイヤーをスキップすることができます。