What is business logic?

[eluser]greedyh4mster[/eluser]
Hiya!

From my understanding about MVC, a better practice of it is to use the M in the pattern to contain the business logic and the interaction with database, also known as the 'Skinny Controller Fat Model'. Instead of leaving the business logic to the controller while the model handles only the database queries. One of the references I read regarding my point above is this link.

While reading, I have this question in mind. What exactly does it means by business logic?

For example:

In a model:

Code:

function hash_password($password){
   $this->password = md5($this->password.$salt);
   return $this->password;
}

Is hashing of password consider a business logic? In my assumption, I think it is. But if hashing of password is really considered a business logic. Then wouldnt generating the password salt be considered as a business logic as well?

For example:

In a model:

Code:

function generate_salt(){
   $this->load->helper('string');
   $this->salt = random_string('alnum', 10);
}

And above all those questions. While I am coding an application, I tends to use integer to determine the status/state of an object. Is this the 'best practice'? Or is there any better way?

For example:

I am writing a notification class. A user will be able to set a notification to either 'dismiss' or 'remind me later' which will in turn determines whether should a notification be displayed to a user in their account page or not.

So in the database, I would have an integer (0 or 1) field named 'status' to determine whether is it a 'dismiss' or 'remind me later'.

In the application level, I used the config file to 'give a name to these values'.

For example:

In the config file:

Code:

$config['notification_status_dismiss'] = 0;
$config['notification_status_remindmelater'] = 1;

So my question is. When I am determining the status of the notification (this means I will be using the item stated above in the config), are the above considered as business logic? Or are they simply just 'php logic'?

An example of considering it as a business logic:

In the controller:

Code:

function dismiss(){
   $this->notification_model->dismiss();
}

function remindmelater(){
   $this->notification_model->remindmelater();
}

In the model:

Code:

function dismiss(){
   $this->status = $this->config->item('notification_status_dismiss');
   $this->_set_status();
}

function remindmelater(){
   $this->status = $this->config->item('notification_status_remindmelater');
   $this->_set_status();
}

Another example:

In the controller (Trying to save a notification in the database):

Code:

function create($user_id, $action, $message){
   $this->notification_model->user_id = $user_id;
   $this->notification_model->action = $action;
   $this->notification_model->action = $message;
   $this->notification_model->save();
}

In the model:

Code:

function save(){
   $this->time = date("Y-m-d H:i:s", time());
   $this->db->insert('notifications', $this);
}

In the above example. The notification has a time field to keep track of the time when is the notification created on. If I based the theory on a controller is to 'redirect user's input to a model only', then the above example would be correct in that sense. Indirectly, it would also means that the 'time field' is considered as part of the business logic right?

Seriously need everyone to help me in pointing me to the correct direction of the MVC pattern. Like what is considered as a business logic? What is not?

Thank you guys for reading!

[eluser]charlie spider[/eluser]
There's no set laws about how you have to use MVC.

My personal understanding is that BOTH the controller AND the model are part of the business logic, the view is the presentation logic and the database is obviously the data. But for others the model is an integral part of the data level and the three levels of MVC translate directly to the three levels of a three tier application.

Models that are written specifically for one particular database table could be considered by some as part of that data level. I use my model for generic non-specific CRUD stuff but keep all of the details in the controller. So my models don't apply to any particular table or database so I don't consider them part of the data layer.

So for example, I have a function in my main model for returning a key->value array from a table, but it is in the controller that I dictate what column will be used for the keys, what column will be used for the values, what table the data is to be pulled from, and even whether the array is to be ordered and by which column to use for ordering. This keeps a lot of redundant code out of my controllers, but in no way are my controllers "skinny".

For more OOP type programming I would think that more logic would get pushed into the model, but maybe not. I tend to write more procedural stuff and my methods make sense for me. If you are working with a team, then you have to do what works best for the team.

Ultimately though, do what makes the most sense for you in your particular enviroment/situation. Maybe you will use a "fat" controller on one project and a "skinny" one on another project. Some people don't use models at all and have all of the non-presentation coding (the business logic) in the controller. Whatever floats your boat.

With regards to your example, I think you could simplify it greatly by only having one field to determine your dismiss/remind status.

Lets' call it "notification_reminder"

if "notification_reminder" is set to 0, or "0", or FALSE, or NULL, then there will be no reminder

if "notification_reminder" is set to 1, or "1", or TRUE then there will be a reminder

they are basically the two sides of the same single coin

your method duplicates the functionality (unless I am missing something else you are intending to do) and opens up the possibility of errors. You are using two coins, one for "heads" and one for "tails".

What if somehow, an update gets interupted, and you end up with both the "dismiss" AND the "remind_me_later" fields set to TRUE ??? What kind of comedy hijinks will that bring about?

Ummm.. the coin toss resulted in both "heads" and "tails"!?!?!?!