I had a controller POST action that is called List that accepts a status variable which can be the following values { “all”, “active”, “inactive}. Then I made repository calls based on the the value of “status” inside of the controller. The controller looked like this:
[HttpPost]
public ActionResult List(string status)
{
return View(GetJobTitlesByStatus(status));
}
private IList<JobTitle> GetJobTitlesByStatus(string status)
{
IList<JobTitle> jobTitles;
switch (status)
{
case "All":
jobTitles = jobTitleRepository.GetAll();
break;
case "Active":
jobTitles = jobTitleRepository.GetActive();
break;
case "Inactive":
jobTitles = jobTitleRepository.GetInactive();
break;
default:
jobTitles = new List<JobTitle>();
break;
}
}
I decided that the code in the switch statement was too much to be inside of a controller, so I extracted this out into a service and this service then makes the appropriate repository calls. For example:
public class JobTitleService : JobTitleRepository, IJobTitleService, IJobTitleRepository
{
public JobTitleService(ISession session) : base(session) { }
public IList<JobTitle> GetJobTitlesByStatus(string status)
{
IList<JobTitle> jobTitles;
switch (status)
{
case "All":
jobTitles = base.GetAll();
break;
case "Active":
jobTitles = base.GetActive();
break;
case "Inactive":
jobTitles = base.GetInactive();
break;
default:
jobTitles = new List<JobTitle>();
break;
}
return jobTitles;
}
}
I personally think this works great, expecially since I’m using dependency injection to get the service into the controller. I have the following questions:
1) Do you think it is a good idea to extract the switch statement logic from the controller?
2) Do you think that having JobTitleService inherit from JobTitleRepository is better than
having an IJobTitleRepository passed into the constructor of the Service (using dependency injection)?
3) Is there a special name for the Design Pattern used for the the JobTitleService?
Yes – your controller should be responsible for selecting a result, preparing the model and then passing the model to the view for rendering. Everything else should be delegated somewhere else, typically services. Taken directly from wikipedia:
No, your service should not inherit from the repository. The service needs to collaborate with the repository to do its function – thus it is a ‘has-a’ not an ‘is-a’ relationship. Right now this might not be obvious as your service is just a pass-through to the repository but as soon as your service begins to do what services are supposed to do (co-ordinate actions from one or more collaborators) it’ll become immediately apparent as you will only be able to inherit from one of those collaborators.
In fact, in this case if your service is only ever going to be a a direct wrapper around the repository it’s not adding anything and is just a layer of indirection – if it stays that simple I would dispense with it and query the repository directly. Usually though things don’t stay that simple for long though.
No, not really.