Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What are the differences btw MVC and Front Controller design patterns?

 
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
read subject please
 
Hung Tang
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nice explanation!
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic