One of the
most known and used pattern of the presentation layer of web applications in
many platforms and technologies is a Model View Controller pattern. I have
worked as software developer in many projects building complex web applications
based on JEE architecture, and the following dilemma was quite often present.
Having one controller, dealing with different logic, to
satisfy a considerable range of views and models logic, with specific functions
for each page, result on complex controller, that with time become error-prone,
time consuming and hard to maintain.
other hand, building an entire new controller for each screen does not just
mean lots of classes, it makes the application harder to extend. If we wanted
to build a logging mechanism, for example, we would have to add logging code to
each controller separately. In fact, there are lots of things we might need to
do for every request: implement navigation, maintain session information, and
gather statistics, to name a few.
A pair of
patterns helps balance these two approaches. The Front Controller pattern
advocates building a single controller that performs common functions on each
request, but delegates other functions to a page-specific controller.
Decorator pattern then shows how to dynamically expand the front controller. The Front Controller pattern is stand for a controller that has a fairly
simple role, it deals with common tasks, and then forward control on to a
The specific functions
of updating the model and choosing the view are delegated to a page-specific
The principle was suggested by management thinker Joseph M. Juran. It was named after the Italian economist Vilfredo Pareto, who observed that 80% of income in Italy was received by 20% of the Italian population. The assumption is that most of the results in any situation are determined by a small number of causes.
The Forming – Storming – Norming – Performing model of group development was first proposed by Bruce Tuckman in 1965, who maintained that these phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results. This model has become the basis for subsequent models. https://www.youtube.com/watch?v=2AXOSQT5yVQ
To play lego with your applications, think about using the following patterns:
Gateway: An object that encapsulates access to an external system or resource (Patterns of Enterprise Application Architecture, Fowler et al. Addison-Wesley, 2004)
Every gateway eliminate a direct dependency with the business logic implementation and details like protocols, communication means and mechanisms behind the gateway.
Possibility to wrapp methods, to have control about the asynchronous and synchronous character of the API.
Extern applications will not access the data model directly, witch can improve security, and increase maintenability (It reduce coupling between business logic, platform dependent logic and the data model).
Depending on the needs of every system the gateway can be unidirectional or bidirectional.
The pattern Plugin: This pattern extends the behavior of a class by allowing extensions to plug into an abstract class that, in turn, plugs into a core class. This creates a new subclass that includes only the capabilities required in the specific context.
The communication with every extern system will use its own gateway.
The integration with every business logic third application is P2P (Point to point). Communications with Webservices can be concentrated by an ESB tool. Where we could plug and play the different gateways
The ease of testing, by:
Separting clearly concerns of each gateway, functionaly, facilitating unit testing.
Pluging and playing mocks gateway implementations that simulate the functional purpose of the gateways.
To adequate to a change all you have to do, is to develop the new implementation of your interface contract, and then plug and play.