I am studying mvc5 in asp.net and wondering if there is a general rule when to use a controller. If I have a business object like Employee will I create a controller named Employeecontroller? But why and what is the benefits of having a controller in the first place?
I want to understand when to create a controller and what the benefits is. I have been looking in mvc5 tutorials but they don’t say when to create controllers.
2
You use a controller when you have a need to access a resource externally. So if you’re building an interface to modify employee information, then you have a need for a controller there.
Just because you have a resource, though, doesn’t mean you need a controller for it. Suppose you have a location class/model that refers to addresses. Maybe an employee has many locations but those locations are all manipulated through the employee views. Well in this case, the employee is still the resource being accessed so you don’t need a LocationController. You will need a view to represent that model probably, but that would be accomplished with partial views.
Controllers should be used to govern the actions necessary within an application to control access to resources. The trick is really to define: What is a resource and what is simply a supporting class?
A controller is the mediator between the model and the view. Essentially, the controller reads the user input from the view, and updates the model in accordance to the changes.
Without a controller, the view will be too tightly coupled with the data model. If you were to change one small thing in the model, it could completely screw up the view. Whereas if you have a controller, a change to the model does not do anything until you wire it into the controller and view.
The whole point is separation of concerns. You can mentally think of the view as the user interface, the controller as the place where you place business rules etc., and the model as the data you want to interface with. Without such a separation, you will have controller logic in both the view and the model, and the code will become hell to maintain and enhance.
The whole point of MVC is decoupling layers from each other. UI work can be done independent of business rules. Business rules can be crafted independently of the UI or data access. And the Model can mine away all the data it wants independently of the Business rules.
Notice that the UI and Model shouldn’t ever know of each other.
“Business logic” about the Employee is what should go into EmployeeController. And when do you create a controller? When you have business logic to capture about a system object. Well, what’s business logic? Essentially it’s the rules about acting upon Employee or other object that aren’t artifacts of the UI or artifacts of the persistence layer.
The advantage of this is that each layer is easier to test as they are providing, in essence, a contract to the other layers. Another advantage is that multiple UIs can utilize the same controller without requiring a rewrite (or a copy & paste) of the existing controller.
It’s really a matter of opinion. In the standard MVC pattern for web applications, you have one controller per action the user performs, but like many other modern implementations of the pattern, Asp.net MVC allows you to have multiple actions in a single controller class. Grouping them by entity they affect is one option, as is having a class for each action, and I’m sure there are other patterns you could use too. I suspect the only important thing is to pick a strategy and be consistent about it, otherwise you’ll struggle to find your controller implementations.