Un modelo base en PHP MVC, ¿bueno o malo?

Question

Estoy escribiendo mi propio framework MVC en PHP, solo para fines de aprendizaje. No fue realmente difícil tener una clase enrutador/despachador para llamar al controlador/acción correcto, etc.

Pero ahora estoy en la parte en la que voy a usar modelos. O en realidad, la capa del modelo. Pero hay algo que me confunde.

Muchos otros frameworks MVC tienen un 'BaseModel'. He leído que esto es una mala práctica, porque el "Modelo" no debe verse como otra clase. Pero como una 'capa' real, que puede contener elementos como el patrón 'asignador' o el patrón 'repositorio', etc.

Pero para ser sincero, no veo ninguna ventaja en eso. Para mí, una clase 'BaseModel' parece ser la forma más rápida de hacerlo, con los mismos resultados.

simplemente puedo hacer algo como:

class User extends BaseModel 
{ 
    // the GetUserBy* could easily be something that's handled by the 
    // BaseModel class, like in the Repo pattern. 

    public function getUserByName ($name) 
    { 
     // no error handling of any kind, just for simplicity 
     return $this->db->exec("SELECT * FROM users WHERE name='".$name."'"); 
    } 

    // $data = array 
    public function saveUser ($data) 
    { 
     // Make sure no extra fields are added to the array 
     $user = array ('name' => $data['name'], 
         'address' => $data['address']); 

     $this->db->autoSave ($user); 
    } 
} 

Pero si yo iría a un patrón repositorio entonces tengo que crear los siguientes: repositorios Entidades DAO

Las entidades tienen agregados a otros repositorios. Básicamente estoy escribiendo manualmente mi esquema de base de datos completo para objetos ...

Al final, ¿cuál es la diferencia? Excepto que probablemente podría haber ahorrado un montón de tiempo simplemente usando una clase de BaseModel ...

¿Pero por qué todavía se considera algo malo? No es que el patrón repo desacople mi aplicación más de lo que estoy haciendo ahora. Porque para mí, esos patrones mencionados anteriormente parecen estar muy sobrevalorados. Probablemente solo funcionaría en una aplicación que tiene un estado compartido; Guarde objetos localmente (en el repositorio) y confírmelos más adelante.

Es por eso que creo que nadie puede responder a esta ...

pero todavía estoy esperando ver una respuesta decente que me hace ir: "ahhhh ... ¿Qué estaba pensando .... ". Pero si no, entonces estoy seguro de mi caso de que el BaseModel no es nada malo y que la mayoría de los bloggers son solo un montón de ovejas :-)

Answer 1

No es que el patrón de recompra desacopla mi solicitud más de lo que estoy haciendo ahora

Su aplicación está estrechamente unida a los componentes de base de datos SQL (que son, en efecto, actuando como su mapeador) . Sin embargo, a pesar de esto, su diseño se parece mucho más a un Repository que a un enfoque Active Record (que es probable que la mayoría de estos bloggers a los que hace referencia estén molestos).

registros activos encapsulan no sólo los datos, sino también el acceso a la base de datos:

$user = new User(); 
$user->setUsername('jane'); 
$user->setEmail('jane@foo.bar'); 
$user->save(); 

Es mejor tener los objetos de registro sean conscientes de la capa de persistencia (separación de intereses). Su "base" hace precisamente eso al devolver matrices de datos de usuario y cuando esas matrices se modifican, deben pasarse a la "base" del usuario para su guardado. Puede cambiar su nomenclatura a:

class UserRepo extends BaseRepo 
{ 
    // user-specific repo code... 
} 

$userRepo = $this->getRepo('User'); 
$user = $userRepo->getUserByName('jane'); 
$user['email'] = 'jane@new.email'; 
$userRepo->save($user); 

No hay nada de malo en tener un repositorio base.

Answer 2

La clase Model debe ser abstracta, solo definiendo métodos sin implementarlos. En cuanto a su modelo User, puede escribir fácilmente una interfaz GettingUsers que tendría todas esas funciones, e implementarla en el modelo User.

Answer 3

No utilizaría ningún modelo base, ya que la mayoría de sus modelos no tendrán una interfaz uniforme con la que se ajusten. Podrías crear una clase base para varios tipos diferentes de modelos (que es solo programación básica orientada a objetos) si así lo deseas.

En general, creo que se supone que los modelos son los componentes "sueltos" que se conectan con un controlador y se muestran con una o más vistas. Realmente no pueden tener una interfaz uniforme porque todos harían cosas diferentes: algunos ni siquiera pueden hablar con un almacén de persistencia, algunos pueden no ser persistentes y/o algunos pueden estar compuestos por otros modelos.

Answer 4

Si está intentando aprender buenas prácticas de MVC a partir de frameworks PHP, entonces lo está haciendo mal. Incluso los mejores marcos en PHP están plagados de fallas y errores de diseño.

Los marcos que tienen "BaseModel" generalmente están implementando algún tipo de ORM. Y el patrón más popular aquí es ActiveRecord. Es bueno para las tablas simples, sin relaciones con los demás (básicamente - getters/setters glorificados). Pero comienza a descomponerse, cuando se trata de estructuras y consultas más complejas. Por lo general, causa extenso technical debt.

La otra razón por la cual este enfoque causa problemas es que su "modelo" en este caso también tiene responsabilidades. Su lógica de negocio está estrechamente ligada al almacenamiento y el almacenamiento está soldado a la lógica. A medida que la aplicación crezca, tales "modelos" acumularán ataques.

Y no, el "grupo de bloggers" no son ovejas. Acaban de leer libros sobre arquitectura de aplicaciones y programación orientada a objetos. ¿Cuándo fue la última vez que leíste un libro sobre este tema?