MVC in Agavi
MVC and High-Level Application Structure
Agavi implements the Model-View-Controller (MVC) architectural design pattern to provide structure to applications. Agavi's interpretation of MVC is quite conservative, and it is very important that you understand both how the three key parts of the MVC concept come together and how Agavi implements them.
MVC architecture defines three distinct parts of an application. Models contain the application's logic. Controllers interpret requests from the user interface and direct Models. Views question Models, and prepare and send output to the user interface.
The Model-View-Controller architecture offers certain advantages. Without in-depth discussion it is sufficient to say that the MVC approach — combined with Agavi's naming conventions and framework facilities—makes it possible to write dependable, testable and extensible code.
MVC in Agavi
A Model represents an unit of logic in your application. In Agavi, a Model is a PHP class. Its methods solve some sort of application-specific problem: for example, sending promotional emails to customers, or maintaining the customer database. Your application may be implemented entirely inside a single Model or across dozens of Models that represent various areas of your software. Some Models act as wrappers for external libraries and even other applications or interfaces. A newly created Agavi Model is just an empty class.
A Controller component is called an Action in Agavi. Just like Models, Actions are PHP classes. Their methods are called by Agavi at the appropriate time.
Actions have one or more corresponding Views. When a Web request arrives, the routing mechanism selects the initial Action to be executed; the Action performs necessary changes in application state by calling the Models; it also selects ("appoints") one of its Views to be executed after it finishes. After that, the appointed View performs rendering of the application's output.
Since HTTP works under the request-response model, Actions correspond to HTTP request handling, and Views to response compilation.
Actions and Views should not implement any part of the application's domain logic. They serve merely as glue between the user interface, request overhead, and the Models. This means that your entire application sans the user interface should be implemented by using Models.
Actions, Views and Models are grouped into Modules. A Module is simply a directory that contains Actions, Views, templates, module-specific Models, validators, local configuration and whatever else that is only needed by a specific Module. Agavi Modules can be found in your application's app/modules/ directory.
Agavi also has global Models and templates. They reside in app/models/ and app/templates/.

