Every Agavi Application consists of one or more Modules. Modules are a means of structuring an application, and offer various configuration and control abilities, such as per-module autoloading, dedicated filters, bundled models and more.

Each Module contains one or more Actions. Actions contain logic code and are totally independent of the way you're using them, be it through a normal web application, or via a SOAP interface - the code remains exactly the same, you usually never touch them again once they are finished. If you're wondering what role Actions play in the MVC pattern, the most accurate explanation would likely be that they are a bridge between Controller and Model, but a lot closer to the Controller than to the Model - think of Actions as parts of the Controller which are loaded on demand.

Once an Action finished execution, control is passed to the View, which handles all presentational aspects of the Action that was executed, like redirection, forwarding to other Actions, HTTP headers, the layout and Templates to use, Cookies and so on. This separation reduces a lot of redundant code and guarantees maximum flexibility of your business logic - as aforementioned, it's simply a matter of throwing in a new Template if you want an existing Action to output, say, JSON in addition to plain HTML.

Models encapsulate business logic transactions and offer a fully transparent API to the Actions that use it, thereby allowing you to change the underlying implementation without having to adjust any other code. The more logic you put into Models, the fewer lines you have to write in your Actions, and you get the benefit of universal code reusability - not only within your application! While Models may be bundled with a Module, they can also be "global" to your application, and you may, of course, share Models across applications. You don't even have to re-implement existing code - if you already have classes that serve as models, you can use them as Models with Agavi, too.

Last but not least, there's a whole bunch of configuration files (of which only three are mandatory!) that allow you to configure all aspects of the Framework. You may even have different configuration settings per Environment and Context (see Environments and Contexts) for maximum flexibility and convenience. Also, it's easy to centralize single parts or complete chunks of configuration files, or you can offer smart presets for your applications, by referencing other configuration files and using them as "parents" from within your application configuration files. This cascade of configuration files that are used is not limited in length, so you can have multiple levels of global definitions for your applications if you like. For example, the default autoload.xml uses Agavi's own autoloading definitions as the parent, making upgrades totally painless because your application's autoload.xml contains only your own declarations.