The controllers in my ASP.NET MVC web app are starting to get a bit bloated with business logic. The examples on the web all show simple controller actions that simply pull data out of a repository and pass it to the view. But what if you also need to support business logic on top of that?
Say, for instance, an action that fulfills an order also needs to send an e-mail out. Do I stick this in the controller and copy/paste this logic to any other actions that also fulfill orders? My first intuition would be to create a service like OrderFulfillerService that would take care of all this logic and have the controller action call that. However, for simple operations like retrieving a list of users or orders from the database, I would like to interact directly with the repository instead of having that call wrapped by a service.
Is this an acceptable design pattern? Controller actions call services when they need business logic and repositories when they just need data access?
Best Answer
Your controllers (in the MVC project) should be calling your objects in the Service project. The services project is where all the business logic is handled.
A good example is this:
or with Dependency Injection (my fav)
Now .. what's the Service project (or what is ProductServices)? that's a class library with your business logic. For example.
but that might be all so hardcore and confusing... so a simple version of the ServiceProduct class could be (but i wouldn't really recommend) ...
So there you go. You can see that all the logic is in the Service projects, which means u can reuse that code in other places.
Where did i learn this?
From Rob Conery's MVC StoreFront media and tutorials. Best thing since sliced bread. His tutorials explain (what i did) in good detail with full solution code examples. He uses Dependency Injection which is SOO kewl now that i've seen how he uses it, in MVC.
HTH.