Is it bad practice for the service layer to have methods that don't deal with the database?

Question

I've got the following methods in my User Service

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

you'll notice that there are a few methods that don't deal with the database, but I felt that this was a good place to use them.

Is this considered bad practice?

note: my Repository Layer strictly deals with the database. My flow goes.

Database > LINQ (DBML) > Repository Layer > Service Layer > Controller (or other).

Answer 1

Example that you have sighted, it seems like a bad practice. If you see all the information that you are asking from your service layer is actually available on your controller itself. Why would you like to cross application boundary to get this information?

However there might be a valid reason to have an operation on service layer which is not exactly dealing with DB.

In your case I would say to use a helper class of something like that in controller.