Cakephp application structure

Cakephp is based on an MVC architecture that is both powerful and easy to understood: Controllers, Models and Views guarantee a strict but natural separation of business logic from data and presentation layers. If I want to enplane by one line, then I will say that, view for the user to see, model for the connection between DB and application and controller is the big boss who controlled everything. Now I want to give some description.

Controllers contains all of the logic of your application. Each controller can offer different functionality depends on the business logic; controllers retrieve and modify data by accessing database tables through models; and they register variables and objects, which can be used in views.

Models are active representations of database tables: they can connect to your database, query it (if instructed to do so by a controller) and save data to the database by creating the object of the represented table. It is important to note that in order to correctly apply the MVC architecture, there must be no interaction between models and views: all the logic is handled by controllers. That means a model create a abstract object and maintain the connection with DB. Serve the purpose according to controller to retrieve, save, update and delete data.

Views can be described as template files or output that present their content to the user: variables, arrays and objects that are used in views are registered through a controller. Views should not contain complex business logic; only the elementary control structures necessary to perform particular operations, such as the iteration of collected data through a foreach construct, should be contained within a view. Throw a view, a user can give input and get output from the application. Its just used for this.

This architecture can greatly improve the maintainability and the organization of your site’s code:

1. It separates business logic from presentation and data retrieval.
2. A site is divided into logical sections, each governed by a particular controller.
3. When testing and debugging an application, any developer accustomed to CakePHP’s structure will be able to locate and correct errors without knowing all of the details of the code.

Controllers, models and views are stored in pre-defined directories within CakePHP’s directory structure. Here’s the directory structure that’s used:

• app/
• config/
• controllers/
• models/
• plugins/
• tmp/
• vendors/
• views/
• webroot/
• cake/
• config/
• docs/
• libs/
• vendors/

This directory scheme must be preserved, as it is essential if the framework itself is to work. Cakephp, like ROR, believes in the importance of convention over configuration: in order to deploy an application, rather than modify dozens of different configuration files, it’s important only to place everything in its proper place; then, you can let the framework do the rest.

Although this may seem worrisome for some developers, it’s a good compromise that can really accelerate the development process.

CakePHP features Controller, Model, and View classes, but it also features some additional classes and objects that make development in MVC a little quicker and more enjoyable and improve efficiency. Components, Behaviors, and Helpers are classes that provide extensibility and reusability to quickly add functionality to the base MVC classes in your applications.

Always a developer have to know one thing. Developer create a CONTROLLER for a specific business logic, create models for each DB TABLE and create views for each function if the view is necessary. For view, developer have to create a folder under app/view/ folder.

Controller Extensions (“Components”):

A Component is a class that aids in controller logic. If you have some logic you want to share between controllers (or applications), a component is usually a good fit. As an example, the core EmailComponent class makes creating and sending emails a snap. Rather than writing a controller method in a single controller that performs this logic, you can package the logic so it can be shared.

Controllers are also fitted with callbacks. These callbacks are available for your use, just in case you need to insert some logic between CakePHP’s core operations. Callbacks available include:

• beforeFilter(), executed before any controller action logic
• beforeRender(), executed after controller logic, but before the view is rendered
• afterFilter(), executed after all controller logic, including the view render. There may be no difference between afterRender() and afterFilter() unless you’ve manually made a call to render() in your controller action and have included some logic after that call.

View Extensions (“Helpers”):

A Helper is a class that aids in view logic. Much like a component used among controllers, helpers allow presentational logic to be accessed and shared between views. One of the core helpers, AjaxHelper, makes Ajax requests within views much easier.

Most applications have pieces of view code that are used repeatedly. CakePHP facilitates view code reuse with layouts and elements. By default, every view rendered by a controller is placed inside a layout. Elements are used when small snippets of content need to be reused in multiple views.

Model Extensions (“Behaviors”):

Similarly, Behaviors work as ways to add common functionality between models. For example, if you store user data in a tree structure, you can specify your User model as behaving like a tree, and gain free functionality for removing, adding, and shifting nodes in your underlying tree structure.

Models also are supported by another class called a DataSource. DataSources are an abstraction that enable models to manipulate different types of data consistently. While the main source of data in a CakePHP application is often a database, you might write additional DataSources that allow your models to represent RSS feeds, CSV files, LDAP entries, or iCal events. DataSources allow you to associate records from different sources: rather than being limited to SQL joins, DataSources allow you to tell your LDAP model that it is associated to many iCal events.

Just like controllers, models are featured with callbacks as well:

• beforeFind()
• afterFind()
• beforeValidate()
• beforeSave()
• afterSave()
• beforeDelete()
• afterDelete()

The names of these methods should be descriptive enough to let you know what they do.

Application Extensions:

Controllers, helpers and models each have a parent class you can use to define application-wide changes. AppController (located at /app/app_controller.php), AppHelper (located at /app/app_helper.php) and AppModel (located at /app/app_model.php) are great places to put methods you want to share between all controllers, helpers or models.

Although they aren’t classes or files, routes play a role in requests made to CakePHP. Route definitions tell CakePHP how to map URLs to controller actions. The default behavior assumes that the URL “/controller/action/var1/var2” maps to Controller::action($var1, $var2), but you can use routes to customize URLs and how they are interpreted by your application.

Some features in an application merit packaging as a whole. A plugin is a package of models, controllers and views that accomplishes a specific purpose that can span multiple applications. A user management system or a simplified blog might be a good fit for CakePHP plugins.