I'm trying to learn some best practices while I ramp up on MVC4. I have a solution with three projects:

  1. Web: MVC stuff
  2. Core: Data Model
  3. Tests: Testing classes

I'm now trying to add:

  1. Services: Business Logic

This will take logic such as "GetFilteredItems()" from my controllers and place them into a Service project, which depends on Core, and upon which Web depends. Nothing to do with HTTP requests. As I'm beginning to do this, I want to honor single responsibility and create one class per method. My questions:

1) Is this a good approach?

2) Say I need a GetFilteredItems method that takes an ID and returns a List. What's the convention here in terms of naming classes and methods? I can't have a class SampleClass with a method SampleClass() that returns something, right?

1 Answer 1


I think a better approach would be to a create a service class for each data model entity. This will reduce the coupling that will result if you created one class per service method. Using the single responsibility model would result in several classes with names like: SortUserByFirstName, SortUserByLastName, SortUserByPhoneNumber, etc. Delegate such a responsibility to a single class such as: UserService, and have methods like sortByFirstName, sortByLastName, etc.

To give an example of what might happen, say you change you data entity named User to SuperUser. Now you would have to go through each single responsibility class and change the class name. Using the more cohesive model I suggested, you change the name of the service class only.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.