Front controller architectural pattern.

Introduction -

Let me tell you something that will make you very happy :). Think about a team without having a manager, no one is there to manage you. You are free to work like you want and can behave as you like. Sounds exciting right?

Unfortunately this way of working has lots of demerit. Now think about what manager does in high level, if there is any request from outside of the team, it will first go to your manager. He will either reject that request or figure out the nature of request, then resource (or resources) who can complete that work, then assign it accordingly. Apart from this manager has other works as well, but listing down them is not my intention here.

Let me think about a team which doesn't have a manager. 

As shown in diagram, team X doesn't have any manager and has 7 employees. I am listing out demerits of having this approach -

1. Before, manager was taking care of incoming request, now client has to remember all team member (like kind of work they do, contact number, how to reach them,etc), so many things, which may look easy for small team but very tough if team size is big. 
2. There will be many requests which requires more then two resources. For that kind of work, team members have to approach to each other, and as now without manager there will not be any standard approach, that process will become a mess as you can see below -

3. It will introduce delay. As you can see there is no work flow, everything is random.Think about all team members as modules and has logic to call each other, now think how much code you have to insert just to make sure everyone can talk to each other. Now what if a new module get introduced to solution, first you have to update code in all modules to make sure all can talk to a new module, secondly include huge code in the new module to talk to all other modules.

We have seen the problem, lets discuss about the solution part. We can solve this random and bad flow of work (or execution) through front controller architectural pattern (sometimes manager design pattern).

Controller design pattern -

According to design principles no component should talk to each other. There has to be a controlled entity who will talk to all component.

Designers has controller (or manager) who will control all its component like mentioned below -

Now how easy it is for client to interact with solution, he just has to pass the call to controller and rest of the work controller will take care.

Basic rules of using controller -

There are some basic rules you have to keep in your mind listed below -

1. Control will flow in single direction (unidirectional).

component/module should not control controller entity. In a very large system it may end up with deadlock.

2.  It should be strict Singleton. We should not have two (or more then two) controller/manager controlling same component/module otherwise, it will again lead to deadlock.

3. There will be only 1 entry and exit point in your solution. Means all request and response has to go through controller otherwise there is no need to implement controller in your design.

4. Controller should not contain any business logic in it. its job is to delegate the control to respective modules that's it. It should not have any logic to process the data and trying to solve it partially before delegating it to some module. Same like typical managers in our team no need to think how request will get resolved, just delegate the work to team member.

If you put logic in controller it will become very slow as it has to handle request from N number of clients, if he starts looking into solution space he will not be able to handle frequent client requests.

5. If we need more then one module to solve the request it has to go through either controller or mediator design pattern in any case, components/modules should not talk to each other.

Example -

Think about a big solution which has many sub system inside it. How you will design it in first place. I am showing a small blog below to understand controller better -

System X will have many sub systems ( A, B and C as in our block diagram). All sub system will act like an individual system that's why we have implemented different controller for different systems.

Thanks for reading it. To read more on design patterns and basic design principles please see my web page. You can also join me on FB or on G++. Please drop comments for any question related to this blog.