3

In GRASP (http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) ), a controller (use case controller) is defined as:

A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have a single UserController, instead of two separate use case controllers)

I can see some similarities of this and MVC controller. However I don't see a standard guideline on how to design a MVC controller. Most of the time people just say it's up to the developer and the design of the application. So I'm wondering whether I can use guideline above to design MVC controller?

To be more specific, let's say an application has a page to display a list of products in a table. Each product is displayed as a row. Each row has a button to restock that product (or any other business operation that makes sense). So as I see, this page has 2 use cases (2 business operations): list products and restock product.

From the guideline above, probably I'll have 2 use case controllers for 2 use cases. Are those mapped to 2 MVC controllers? Or just need one Product controller with 2 actions for 2 use cases?

If just need one Product controller, how about a page that has many business operations in the same page? Soon the controller will become too big. Of course if a page has too many operations, it might not be a good UI design, but sometimes developers don't have a choice because clients want it that way to be convenient

2
  • Is your question about how to define the Use-Case Controller and how it is different from a MVC Controller (or fits into the MVC architecture) OR is it "how to define the MVC Controller"? If you are asking about how to define the MVC Controller then this is a duplicate of many similar questions. The basic answer being that there are dozens of different interpretations on defining a MVC Controller, so learn some of those interpretations and pick one that fits your system.
    – Dunk
    Apr 30, 2015 at 16:11
  • My question is more on how use case controller is different from a MVC controller and whether it makes sense to organize MVC controller by use case (like in use case controller) May 1, 2015 at 1:31

2 Answers 2

2

You quoted the Wikipedia article out of context. It actually says:

The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event.

A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have a single UserController, instead of two separate use case controllers).

So a Use Case Controller is a specific type of controller. It doesn't necessarily mean that's how you will organize your controllers, only that it is one way of organizing them.

Controllers can be organized by functional responsibility, department, or whatever organizational pattern makes the most sense for your particular requirements. There is no "standard" way of doing it.

2
  • so you mean use case controller is one way to organize MVC controller? That's what I'm wondering, whether any relationship between use case controller and MVC controller and whether I can use this organization method (by use case) in MVC controller May 1, 2015 at 1:30
  • No, there is no intrinsic relationship between use cases and controllers. Yes, you can organize controllers by use case, if you so choose. How you organize them is entirely up to you. May 1, 2015 at 3:02
1

In MVC pattern, a controller mediates between view and model. Action methods in a controller should be thin and should not have logic embedded in them.In GRASP you can look for Indirection pattern (http://en.wikipedia.org/wiki/GRASP_(object-oriented_design))

So how many controllers should we create or how many action methods should be in one controller, general rule of thumb is to group related action methods in one controllers so that they look clean and well organized.

For your case, I think it would be best to create one controller with below two action methods, as they are very much related to each other. However, the logic for ReStock need not to be in the controller itself.

  1. List
  2. ReStock
2
  • 1
    however sometimes it's not easy to decide whether the 2 actions are related. That's why I'm looking for some more specific guidelines. As I know there are many ways to group actions into one controller, e.g. all operations in one UI page belongs to one controller, or all operations in one use case belongs to one controller. Your suggestion is to group operations in one page into one controller? My concern with that is for complicated page, the controller will become very big (.i.e. with a lot of methods, although it can delegate the actual logic to other classes) Apr 30, 2015 at 8:40
  • If you have a situation where one view is using so many action methods and your controller is not maintainable you can further sub categorize them in multiple controllers, you just have to ensure they look clean and are grouped properly. Apr 30, 2015 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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