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.

Answer 2

@Predeep has a point. Don't put methods belonging in the webproject in the service layer. You are just adding another dependency.

The service layer is not supposed to be just a layer on top of the repository layer. It could contain logic modifying the information from the database or any other data source. It's perfectly fine to add other methods that do not have to do anything with the database. That's what the layer is for. Otherwise you could just skip that layer.