In an earlier post, I mentioned how Applying UML and Patterns by Craig Larman described all nine GRASP Patterns that are useful as a learning aid for OO design with responsibilities. One of the GRASP patterns that I particularly found interesting is Controller which answers the question - What first object beyond the UI layer receives and coordinates (”controls”) a system operation?
Now most people will recognize this as a piece of the Model-View-Controller design pattern. In fact, if you are interested in understanding the Model-View-Controller Design Pattern for ASP.NET applications, Microsoft has a good overview here, although I think the particular example is poor as the controller in the example is a “DatabaseGateway,“ which is truly an unrealistic object in my opinion.
The controller is the first object beyond the UI layer that is responsible for receiving or handling a system operation message. Usually this system operation message comes from the code-behind of an ASP.NET Web Page.
The solution to this problem as pointed out in Applying UML and Patterns is to assign the responsibility to a class representing one of the following choices:
- Represents the overall “system,“ a “root object,“ a device that the software is running within, or a major subsystem - there are all variations of a facade controller.
- Represents a use case scenario within which the system event occurs, often named <UseCaseName>Handler, <UserCaseName>Coordinator, or <UseCaseName>Session (use case or session controller).
- Use the same controller class for all system events in the same use case scenario.
- Informally, a session is an instance of a conversation with an actor. Sessions can be of any length but are often organized in terms of use cases (use case sessions).
The book goes on to explain that the Controller sits in the problem domain, but isn't a domain entity. It delegates to other objects the work that needs to be done; it coordinates or controls the activity. It does not do much work itself.
Facade Controller
If you don't have a lot of messages that need to be handled by the Controller, you could get away with a single object that represents the overall system. For example, if you are building an application that manages your contacts, addresses, and phone numbers, you could call this object “AddressBook.” If you are building an e-commerce website, you could call this object “Store.” If you are building a chess game, you could call this object “ChessGame.“
Use Case or Session Controller
However, as alluded to above, if you have a lot of messages that needed to be handled by a “Controller,” you risk the chance of losing cohesiveness if using a single facade controller. In this case, you should define a single controller for all the system events associated with a single use case. So, in our e-commerce website example above, we may have several use case controllers, called “HandleReturn”, “ProcessSale”, “ProcessPayment”, “ManageAccount”, etc. For most applications, I recommend using a session / use case controller.
It is interesting to actually read an answer to this problem. I can't tell you how many times you hear about the MVC pattern, but it is never explained this well, offering suggested solutions to what object will actually represent the controller.
Good food for thought on your next project.