Best way of passing response information from Mode

The Model View Controller architecture tells me that all my business logic should be inside the Model, while the data flow should be handled by the Controller. Knowing this, while I'm dealing with my logic inside the Model, I need to let the Controller know if he's supposed to redirect to another url, redirect back, what kind of message or variable to pass during the redirection, etc. What is the best way of doing this?

I can think of some ways, like throwing exceptions on the Modeland catching them on the Controller or returning an array from the Model and treating it on the Controller, but none of them seem very nice. The easiest way would be calling the Redirect->to() (or back()) inside the Model and just returning the Model's return on the Controller, but it seem to break the architecture's separation of rules.

Is there a "right" way of doing this? What would be the pros and cons of each way?

回答1:

EDIT:

The answer below is old. Laravel now includes a bunch of different ways of handling common problems.

For example, use Laravel's FormRequest's as a way of validating data easily on controller methods, and Jobs to handle business logic for creating / updating models.

OLD POST:

This is a common question, and while the 'MVC' pattern is nice for a basic starting point for a web app, I feel like the majority of developers always need another intermediate service for validation, data handling, and other problems that come up during development.

To answer your question without bias: There is no right way.

To answer your question with my own personal bias, I feel the majority of developers will use the Repositories or Services pattern to handle intermediate data handling between the controller and the model, and also have separate classes for validation as well.

In my opinion, Repositories are better for a framework and data agnostic design (due their interface driven implementation), and Services are better for handling the business logic / rules. Controllers are better used for handling responses and for passing the input data to the repository or the service.

The paths for each of these patterns are the same though:

Request -> Controller (Validation) -> Service -> Model -> Database

Request -> Controller (Validation) -> RepositoryInterface -> Model -> Database

Validation is in brackets since input isn't passed from the validator to the service / repository, the input sent to the validator, gives the 'OK', and let's the controller know it's ok to send the data to the Service / Repository to be processed.

I only use Services when I'm absolutely positive I won't be changing frameworks or data sources. Otherwise I'll use Repositories. Repositories are just a little more work to setup, since you'll need to make Laravel resolve the interface to your repository class through its IoC.

Services Example:

The Service:

namespace App\Services;

use App\Models\Post;

class PostService
{

    /**
     * @var Post
     */
    protected $model;

    /**
     * Constructor.
     *
     * @param Post $post
     */
    public function __construct(Post $post)
    {
        $this->model = $post;
    }

    /**
     * Creates a new post.
     *
     * @param array $input
     */
    public function create(array $input)
    {
        // Perform business rules on data

        $post = $this->model->create($input);

        if($post) return $post;

        return false;
    }
}

The Controller:

namespace App\Http\Controllers;

use App\Services\PostService;
use App\Validators\PostValidaor;

class PostController extends Controller
{
    /**
     * @var PostService
     */
    protected $postService;

    /**
     * @var PostValidator
     */
    protected $postValidator;

    /**
     * Constructor.
     *
     * @param PostService $postService
     * @param PostValidator $postValidator
     */
    public function __construct(PostService $postService, PostValidator $post Validator)
    {
        $this->postService = $postService;
        $this->postValidator = $postValidator;
    }

    /**
     * Processes creating a new post.
     */
    public function store()
    {
         $input = Input::all();

         if($this->postValidator->passes($input)) {
             // Validation passed, lets send off the data to the service
             $post = $this->postService->create($input);

             if($post) {
                 return 'A post was successfully created!';
             } else {
                 return 'Uh oh, looks like there was an issue creating a post.';
             }
         } else {
             // Validation failed, return the errors
             return $this->postValidator->errors();
         }
    }
}

Now with this pattern, you have a nice separation of all your processes, and a clear indication of what each of them do.

For a repository example, Google 'Laravel Repository Pattern'. There are tons of articles about this.

回答2:

Actually - in Laravel 5 that is not the best way to do it. Business logic should not be in models. The only thing that models should do is retrieve and store data from your database.

You are better off using the CommandBus or ServiceProviders to handle application logic and business rules. There are many articles on the web about these, but personally I prefer laracasts.com as the best learning resource.