What are the differences btw MVC and Front Controller design patterns? Front Controller design pattern is usually discussed in the context of developing web applications. All incoming requests go through a component they called "Front Controller". The Front Controller inspects the incoming request and decides what to do with it; usually it delegates the request to another component in the application that best know how to handle it. If you ever used Struts, they have implemented the Front Controller pattern in their RequestProcessor class (I think this is the right class, I might be wrong) that handles incoming requests and dispatches them to the appropriate Action classes based on the URI entered. These Action classes can perform business logic, and other sorts stuff depending on the request, but its up to the Front Controller (RequestProcessor) to decide which Action gets called. The RequestProcessor is the Controller "c" in MVC of the Struts framework, since Struts is a web application framework. MVC is an architectural pattern and its components include a controller, model, and a view. The pattern encourages a modular design in applications by having three distinct layers. Each layer can be independently developed and maintained, thus the effect is to promote loose coupling among these layers. MVC can be used to design any UI applications, not necesary restricted to web applications. A Front Controller design pattern can be looked at a way to implement the "c" part of MVC in web applications. Hope this helps
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Is it the same difference as between GRASP Controller/Control object in Objectory method and handler objects in the Application layer of the Layers pattern? Being true that the former Controllers redirect the system events (performed by the actor) for the apropiate domain/entity objects to carry out the corresponding system operations; does this imply that Controller objects are needed for the realization of all the use cases? I mean, can we skip the creation of controller objects and force the GUI to call directly to domain objects? In page 465 Applying UML and Patterns some reasons to have an Application layer are: A)multiple GUIs B)distributed system C)domain layer cannot keep state D)a precise workflow of windows or html pages to be presented In case we are developing a standar desktop application should we go for Controller objects to ease the realization of uses cases or should we follow Larman's advice and dismiss them? I have no one else (programmer) to ask my doubts.