PHP OO Duda "teológica" sobre MVC

[destor77]

Hola a tod@s,
hoy los vengo con una duda "teológica" sobre el patrón MVC jeje. Como bien sabemos la idea del MVC es entre otras cosas separar la lógica de la vistas, etc, etc.
Revisando como funcionan la mayoría de los nuevos frameworks he notado que en los controladores hacen esto:

Código PHP:

$posts = DB::table('usuarios')->join('posts', 'usuarios.id', '=', 'posts.user_id')->get();
 

Yo siempre considere que en el controlador solo se hacen la lógica necesaria para devolver los datos del modelo a la vista. Como venia trabajando hasta ahora lo que yo haría es que en el modelo haya si un método "get()" que en el mismo este el join de la base de datos, y en el controlador solo pasar la vista el resultado de

Código PHP:

$post = $modelo->get();
 

En fin mi duda "existencial" es que si llamando con los ORM actuales en el controlador para devolver datos no se esta rompiendo el paradigma del MVC.

Espero que se haya entendido mi duda y desde ya muchas gracias!

[eternoaprendiz]

El ORM de Laravel (como otros ORMs), permite establecer relaciones entre modelos:

http://laravel.com/docs/eloquent#relationships


De tal manera que es posible en el controlador hacer simplemente esto (una vez definidas las relaciones entre modelos):

Código PHP:

$posts = Post::with('users')->get();
$posts = Post::with('users', 'comments')->get();
$posts = Post::with('users.country', 'comments')->get();
 

De todas formas, este sistema, si bien es cómodo y rápido, tiene una pega: no puedes testear sin acceder realmente a la base de datos. Por eso es recomendable trabajar con "repositorios" que proporcionen los datos, de manera que estos oculten el origen (ya sea base de datos, xml, o un simple array para testear).

Ejemplos en Laravel y Symfony:

http://culttt.com/2013/07/08/creatin...-repositories/

http://net.tutsplus.com/tutorials/ph...l-controllers/

http://symfony.com/doc/current/book/...sitory-classes

[masterpuppet]

El MVC no lo rompes pero como bien has notado algo no esta bien, independientemente del fw lo ideal es utilizar DI, un controller es una clase como cualquier otra y si esta tiene dependencias de alguna forma debes inyectarlas, el one-liner que muestras para mi es puro marketing, no utilizo Laravel pero si lo hiciera jamas me saltaría las dependencias de esa forma, simplemente inyectaría el Provider vía constructor.

Saludos.

[eternoaprendiz]

... simplemente inyectaría el Provider vía constructor

Ese mecanismo de inyectar el provider en el constructor está disponible en Laravel:

Por un lado, vinculamos una inteface con un repositorio

Código PHP:

App::bind(
    'Repositories\PostRepositoryInterface',
    'Repositories\RedisPostRepository'
);
 

Y por otro, en el constructor del controlador simplemente tenemos algo así:

Código PHP:

use Repositories\PostRepositoryInterface as Post;
 
class PostsController extends BaseController {
 
    protected $post;
 
    public function __construct(Post $post)
    {
        $this->post = $post;
    }
 
    public function index()
    {
        $posts = $this->post->all();
 
        return View::make('posts.index', ['posts' => $posts]);
    }
 
}
 

De tal manera que si al controlador no le pasamos un Provider Laravel instancia el bind que tenga definido.

Supongo que en otros frameworks puede haber otros mecanismos parecidos. O puede que este sistema tampoco sea lo más recomendado. Todavía no lo he puesto en práctica