Should the business logic be separate from the model?

Question

We're working on a fairly code-heavy PHP5 project, and in the last week I worked on a PoC of a RESTful API. We are separating Model Classes from Business Classes.

Trying to implement CRUD functionality, I discovered, that implementing CRUD against the Models directly would be pretty straight-forward while implementing it against the Business Logic isn't, since its functionality is specific to the currently existing Views and its interface doesn't provide the general data access model I need for implementing the API.

Thinking about this, the following questions came to my mind:

• What is the best way to interact with the data, keeping the flexibility of the model and keeping the functionality the model doesn't care about at the moment (like sending a mail with an activation link when changing the email address)?

• Working a lot with django previously, where most of the business logic is implemented in the model, why should you keep the business logic separate anyway? Do you have any real-life examples? What problems does this solve, if any?

Some possible solutions came to my mind, too:

• Putting the whole business logic into the model. Checking which fields changed after / before calling the save method.
• Using the observer pattern to notify the business objects of changes in the model and interact with the models directly.

What are the pros and cons in your opinion, what would you do?

Answer 1

If you separate out your storage in data a data access layer you get the separation you want and the functionality in the model:

DAL (doing queries etc)
  |
Model (doing business)
  |
Controller
  |
View

So in the view you have an action: Mark as Paid. So you controller gets the request (POST) /invoice/1/markaspaid (or any other url structure you use). Then the controller calls the model:

$Invoice=new Invoice();
$Invoice->markAsPaid(1);

Then your model calls the DAL to actually store this change. There is no real need to separate this from the models. If it is very complex or very transactional you might think about a separate service for a complex task. That way your model gets thinner and the complex part gets separated.

What is the best way to interact with the data, keeping the flexibility of the model and keeping the functionality the model doesn't care about at the moment (like sending a mail with an activation link when changing the email address)?

I don't understand this totally. As far as I see it you should separate the send e-mail process anyway from your normal code run. So put it in a queue and find it out there. It isn't part of your normal code path. You might initiate it from your model but that's about it.

See this question which has relevant info on that topic: Cakephp cron job to call a controller's action