Controller vs. Model - Need explanation

I'm on the beginning of my "Learn MVC" way. Basically, I don't have big problems with object-oriented programming however there's one technical aspect that needs clarification. It seems that my theory isn't quite good enough.

Currently, I'm using KohanaPHP framework, version 3.

Example situation: I have a website, where user can submit an article.

So I have following structure:

classes/
    /controllers/
        article.php
    /models/
        articles.php

So far so good. I don't have problems with models that extends Kohana_Model however I'm not sure if I'm using the correct way models that are using ORM.

Basically when using models extending Kohana_Model I'll put all logical operations in model. Should I do the same for models using ORM? In many example over the Net I saw controllers that was performing logical operations on user input/data from database which is incorrect in my opinion.

Let's say I need to get few rows from database 开发者_高级运维so I create proper method in model and returning the object. I think it's correct, isn't it?

Basically, all operations on user input/data (select from db, insert into db, validation) I put in the models. That's the way I understand MVC design pattern. Models should take care about all "mechanic" operations and controller is only a "bridge" between models/views and it's a "front" engine.

Is it a correct approach?

I know that might be a silly question for more advanced users however I want to learn only good practices. If anyone could deliver some clarification, I'll be delighted.

In short terms, your model performs all operations on the data (be it incoming, outgoing, database, files ... data), and your view should take care of displaying the data. The controller should call the necessary model methods to get the data ready to be passed to the view. The controller shouldn't perform any changes to the data, but it should test it to get the necessary action done properly.

Hope I made it clear enough, let me know if this doesn't clear things for you.

I haven't worked with KohanaPHP but it looks like a 'rails-inspired' Framework. In the rails world it is generally considered best practice to have skinny controllers and fat models.

some background can be found in this old article by jamis buck http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model or in this one concerning cakephp http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

The idea of seperating logic from data is that data does not contain logic, so in your models you should only really be sanitizing data.

Take this example:

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id = false)
    {
        if(!$user_id)
        {
             $user_id = get_guest_id();
        }
        //Insert
    }
}

Seems legitimate logic in the models, but from now on your application must be able to allow guests to post articles, or its flawed and you need to edit the models, which then will floor your other applications / areas of your site

Take this scenario:

You have 2 sites

• ComputerArticles.com
• CookingArticles.com

Now these 2 domains point to the same server but a seperate application in kohona, be not placing any domain logic within your models your able to use the exact sample models accross all your domains.

Your Model Methods should look like so:

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id)
    {
        $this->compile("articles",array($title,$text,$user_id))->insert();
    }
}

And within your controllers you should place all your logic as the logic will depend on the domain.

Think of your Models as an API, where you have multiple sites using the same API But under different logic.

Hope this helps.

Here are the basic layman definitions of the terms - Views: The screens presented to the users Controller: An engine/framework that takes in requests, determines who handles it and delegates them appropriately. Model: This basically tells you what screen to show after so and so action is done on this screen. Think of it as a (directed) graph. The edges emerging from a node are actions and the the nodes they connect to are next screens based on those actions.

So a model basically includes the actions that user does on the screens and their action-handlers. The controller simply calls in a corresponding action-handler for a particular user action and the action-handler is responsible to do something sensible with the incoming request.

Now your question. Where does business logic goes? Well it is the action handler. Or it is abstracted somewhere people like to call - business layer. But anyways it is triggered off from from the action-handlers itself.

So, technically, business logic is part of actions which themselves are part of the Model. This makes sense if you think it this way: The controller handles user interaction and presents views based on the model (actions + business).

** Typos corrected.