All software engineers know the MVC pattern also it is applied in various projects from standalone to web or distributed application. However, while many Software Engineers have different view on Controller layer and many cases it is not managed well because the Controller layer must do many things and it is too big for maintenance! I just copy the definition of MVC pattern here from Wikipedia (http://en.wikipedia.org/wiki/Model-view-controller)

Model

The domain-specific representation of the information on which the application operates. It is a common misconception that the model is another name for the domain layer. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items).

Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

View

Renders the model into a form suitable for interaction, typically a user interface element.

Controller

Processes and responds to events, typically user actions, may invoke changes on the model.

Model and View is easily understand and be maintainable. However, when the TA define the architecture of some specific project, the Controller layer tends to become more complex when the project's size is increased. Base on the standard application, the controller will do:

• Binding the data from view layer to entity objects.
• Format data.
• Validate the constraints (data constraints, application constraints and business constraints)
• Manage variables scope
• Manage the transactions
• Execute business logics
• Call data access layer and save model to persistent place (database for example).

Many tasks are handled in the typical MVC pattern architecture while view and model layer is rather simple and understandable. That is the root cause make some project apply the MVC pattern but still cause the bad quality on architecture. Let's dive in some specific code with me on typical Controller class:

public void execute (...args) {

//Binding parameters from view to entity model

//Format data if any

Date d = DateFormater.format (str);

...

//Validate the constraints

Validator.validator (entity);

// Manage transactions

Transaction.begin();

...

processBusinessRules() {

...

dao.save(entity);

}

...

Transaction.end();

}

The code should be cleaner if we separate the execute methods into several smaller ones. However, the Controller class has many reasons for change. If you need to change the validation rules, you will modify the Controller class. If you need to change the business rule, you also need to modify the Controller class etc. So for each responsibility of Controller layer must do, the architecture should divide it into separate classes, each class only has one reason to change that means each class has only one responsibility.

Base on the above advise, I will have the following interface for each responsibility define above:

• IValidator: responsible for validation
• ITransactionManager: responsible for transaction management
• IService: responsible for specific processing business service
• IDao: responsible for saving entity model to persistent storage.
• ...

Next, the Controller class will combine all classes (instead methods as above example) in one place, so I have the interface IController that makes the Controller layer has tigh coupling with View layer. For specific Controller class, I generalize the overall business processing base on the template method:

class ControllerTemplate implements IController {

IValidator validator;

IService service;

...

public void execute(...args) {

binding.bind(args);

validator.validator(entity);

formater.format(entity)

transaction.begin();

businessHandle();

transaction.end();

}

//need to be overidde

protected void businessHandle();

}

It should be better, if I only need to change the way of binding data, I only modify the Binding class and I do not care about the change will break the rest. The design looks more better and easily maintainable. It could be cause better to make the above class Validator, Formatter, Controller, Service object etc are independent by using some IoC container such as Spring, IoC, Guice ...We have the similar approach in Spring MVC but I do not see the similar approach in standalone application. Forgive me, I do not follow standalone application trends for rather long time , but applying Spring or Guice framework you can make the same thing easily in standalone environment.