What is Kohana?

Kohana is a PHP5 framework that uses the Model View Controller architectural pattern. It aims to be secure, lightweight, and easy to use.

1. Strict PHP5 OOP. Offers many benefits: visibility protection, automatic class loading, overloading, interfaces, abstracts, singletons, etc.
2. Community, not company, driven. Kohana is driven by community discussion, ideas, and code. Kohana developers are from all around the world, each with their own talents. This allows a rapid and flexible development cycle that can respond to new bugs and requests within hours.
3. GET, POST, COOKIE, and SESSION arrays all work as expected. Kohana does not limit your access to global data, but provides XSS filtering and sanity checking of all global data.
4. Cascading resources, modules, and inheritance. Controllers, models, libraries, helpers, and views can be loaded from any location within your system, application, or module paths. Configuration options are inherited and can by dynamically overwritten by each application.
5. No namespace conflicts. Class suffixes and prefixes are used to prevent namespace conflicts.
6. Auto-loading of classes. All classes in Kohana are automatically loaded by the framework, and never have to be manually included.
7. API consistency. Classes that require access to different protocols use “drivers” to keep the the visible API completely consistent, even when the back-end changes.
8. Powerful event handler. Kohana events can transparently be: added, replaced, or even removed completely.

To be secure means to use best practices regarding security, at all times:

• Kohana comes with built-in XSS protection, and can also use HTMLPurifier as an XSS filter.
• All data inserted into the database is escaped using database-specific functions, like mysql_real_escape_string, to protect against SQL injection attacks. magic quotes are disabled by Kohana.
• All POST, GET, and COOKIE data is sanitized to prevent malicious behavior.

To be lightweight means to provide the highest amount of flexibility in the most efficient manner:

• Kohana uses convention over configuration as much as possible.
• Sane defaults and highly optimized environment detection routines allow Kohana to run in almost any PHP5 environment.
• Loose coupling is used to always load the minimum number of files, reducing resource usage.
• A clean API and using native functions whenever possible makes Kohana one of the fastest PHP5 frameworks available.

To be easy to use means to provide understandable API and usage documentation, based on community feedback.

Kohana uses the Model View Controller architectural pattern. This keeps application logic separate from the presentation and allows for cleaner and easier to work with code.

In Kohana this means:

• A Model represents a data structure, usually this is a table in a database.
• A View contains presentation code such as HTML, CSS and JavaScript.
• A Controller contains the page logic to tie everything together and generate the page the user sees.

Credit: External Link

This is just a simple intro post to the concepts of MVC. It is intended for those who are starting to grasp the basics, but are having a bit of a hard time understanding some of the rules and concepts.

We’ll use this interesting analogy that I thought works quite well to further clarify some things…

So, let’s imagine a bank.

The safe is the Database this is where all the most important goodies are stored, and are nicely protected from the outside world.

Then we have the bankers or in programmatic terms the Models. The bankers are the only ones who have access to the safe (the DB). They are generally fat, old and lazy, which follows quite nicely with one of the rules of MVC: *fat models, skinny controllers*. We’ll see why and how this analogy applies a little later.

Now we’ve got our average bank workers, the gophers, the runners, the Controllers. Controllers or gophers do all the running around, that’s why they have to be fit and skinny. They take the loot or information from the bankers (the Models) and bring it to the bank customers the Views.

The bankers (Models) have been at the job for a while, therefore they make all the important decisions. Which brings us to another rule: *keep as much business logic in the model as possible*. The controllers, our average workers, should not be making such decisions, they ask the banker for details, get the info, and pass it on to the customer (the View). Hence, we continue to follow the rule of *fat models, skinny controllers*. The gophers do not make important decisions, but they cannot be plain dumb (thus a little business logic in the controller is OK). However, as soon as the gopher begins to think too much the banker gets upset and your bank (or you app) goes out of business. So again, always remember to offload as much business logic (or decision making) to the model.

Now, the bankers sure as hell aren’t going to talk to the customers (the View) directly, they are way too important in their cushy chairs for that. Thus another rule is followed: *Models should not talk to Views*. This communication between the banker and the customer (the Model and the View) is always handled by the gopher (the Controller). (Yes, there are some exception to this rule for super VIP customers, but let’s stick to basics for the time being).

It also happens that a single worker (Controller) has to get information from more than one banker, and that’s perfectly acceptable. However, if the bankers are related (otherwise how else would they land such nice jobs?)… the bankers (Models) will communicate with each other first, and then pass cumulative information to their gopher, who will happily deliver it to the customer (View). So here’s another rule: *Related models provide information to the controller via their association (relation)*.

In our bank it would look something like this:

• Worker Andy → asks banker Bob Buzzkillington → who asks another banker Jim Buzzdickenson → who gets the loot from the safe (the DB).

So what about our customer (the View)? Well, banks do make mistakes and the customer should be smart enough to balance their own account and make some decisions. In MVC terms we get another simple rule: *it’s quite alright for the views to contain some logic, which deals with the view or presentation*.

Following our analogy, the customer will make sure not forget to wear pants while they go to the bank, but they are not going to tell the bankers how to process the transactions.

Well, that about covers most of the basics. I hope this analogy helps somebody rather than confuses them even further…

Let’s just summarize some rules and concepts:

 1. Fat models, skinny controllers!
 2. Keep as much business logic in the model as possible.
 3. If you see your controller getting “fat”, consider offloading some of the logic to the relevant model (or else bad things will start happening!).
 4. Models should not talk to the views directly (and vice versa).
 5. Related models provide information to the controller via their association (relation).
 6. It’s quite alright for the views to contain some logic, which deals with the view or presentation.