I will try to give you my point of view regarding the GRASP Controller, Page Controller pattern and the Supervising Controller pattern.

For the readers who don’t know what GRASP is, here is a very short description:

GRASP stands for “General Responsibility Assignment Software Patterns”, and there are 9 GRASP patterns that help you with the “basic” aspect of OO design. Some of the 9 patterns are Controller, Creator, Low Coupling, Polymorphism etc.

Most people are probably recognizing the GRASP Controller in the MVC pattern (Model View Controller). When some people talk about the MVC pattern in an ASP.Net application they refer to something similar to this:

View: The .aspx page
Controller: The code-behind (People will often see this as the GRASP Controller).
Model: The business logic or other logic that the controller will make a call to and use.

But for me this is more like the Page Controller Pattern, because we are still in the UI-Layer, and the GRASP Controller pattern belongs more into to the Application Layer (The GRASP Controller is the first object beyond the UI layer that receives and coordinates (”controls”) a system operation.). The rule of the Application Layer in a Domain Driven Design (DDD) is to keep it thin and it doesn’t contains any business rules, and should only coordinate tasks and delegate work to collaborations of domain objects in the Domain Layer.

For example in an ASP.Net Web Form the GRASP Controller will get a message from the code-behind (in an ASP.Net app), and coordinate it to the right object that will do the work. The GRASP Controller will not do the work itself, only delegate the work.

I can see that the name “controller” in different patterns can be confused and have different meanings in different context. In my post about the Supervising Controller, the Controller (maybe it should be Presenter to not confuse people ;)) will have the logic that is often put into the code-behind, only to separate the logic from the View and also make it possible to write unit-test to test the logic.

So if we look at the GRASP Controller once again, it has the responsibility to delegate to another object that will do the work. In my post the Controller will not delegate (or it will to the Repository), but still it will do some work to prepare the presentation of the View and also be the “Presenter”, and is very close to the UI-layer and should not belong to the Application Layer (regarding to me), and the GRASP Controller should not have the responsibility to prepare and be a presenter.

This is my way of see it and maybe I got it all wrong ;)