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?

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.