Is a 'Controller' an example for Facade pattern?

Question

My question is simple. Today, there are a lot of frameworks for both front-end and back-end which implements MVC (Model-View-Control) architecture.

Is 'Controller in MVC' an example for Facade Design Pattern?

Henkel

Answer 1

OK, let me start off by saying this: I don't think the terms "MVC" nor "Facade" are defined well enough to make this a question which is answerable succinctly and absolutely. There are many different "flavors" of MVC each with different properties. So to say clearly "yes" or "no" I think is a bit opinionated, but also not really that useful.

General Answer

I do not believe a Facade and a Controller are the same thing.

If you look at the Gang-Of-Four Design Patterns we can't just go by code structure to determine the meaning or implementation of a pattern. Meaning, you can't look at most code and say "This is a X Pattern obviously".

A quick example of this is a Facade and an Adapter. Both are identical from a code standpoint, so the difference isn't technical but in how you use it. You build an adapter to connect one complex system to another with a defined API (interface). You build a facade when you're creating a new interface for the same purpose. Meaning the difference is whether the newly built layer satisfies an existing interface (adapter) or creates a new one (Facade). Once it's written, there's no difference.

We can say the same thing about Decorator and Proxy. In fact, we can do this for many. I talk about this fact in the first half of my talk Beyond Design Patterns based on this Blog Post by the same name.

The Why Matters

Ultimately, we need to look at why you write the code to see if a controller and a facade are the same thing (or are similar).

Why do you write a facade: because you want to provide a simpler access to a complex system, often for a specific use-case. From Sourcemaking:

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Why do you write a controller: because you want to provide a specific piece of functionality to an "outside user". The controller routes the request to your "model" and interacts with the View.

The what is the same (route a simple interface to a more complex set behind the scenes). A controller in an application acts just like a Facade does in that it acts as a "gateway" to a more complex application for a specific use-case.

The Nuance

I think the question is really interesting because it gets us thinking about the why far more than the what. If you view a controller as a general-purpose abstraction that you can call from multiple places (from HTTP in one case, from CLI in another), then it indeed starts to look a LOT like a Facade.

If however your controllers tend to be used in a single context, then they stop looking as much like Facades, and instead start to look just like general code.

The nuance here is extremely important. In fact, to me, simply asking the question and thinking about the nuance is FAR more important than any answer could ever be.

Bartender

Answer 2

As @ircmaxell points out, there is trouble in answering a question that is not well defined.

For purposes of clarity, I'll use Fowler's definition of an MVC Controller (emphasis mine):

The presentation part of MVC is made of the two remaining elements: view and controller. The controller's job is to take the user's input and figure out what to do with it.

At this point I should stress that there's not just one view and controller, you have a view-controller pair for each element of the screen, each of the controls and the screen as a whole.

I'll use this text about the intent of Facade (from my copy of the GoF):

Intent

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

By these definitions, they're not the same thing.

Now, it's worth mentioning that GRASP Controller (which is not MVC) is often a facade to the application or domain layer(s):

Name: Controller Problem: What first object beyond the UI layer receives and coordinates ("controls") a system operation? Solution: Assign the responsibility to an object representing one of these choices:

• Represents the overall “system,” a “root object,” a device that the software is running within, or a major subsystem (these are all variations of a facade controller).
• Represents a use case scenario within which the system operation occurs (a use case or session controller)

Very