Mi proyecto web tiene una clase llamada DB_CONNECTOR donde se empaquetan todas las funciones que interactúan con la base de datos mysql. Estas serían funciones como get_user() , add_user() , change_user_attribute() y muchas más. En cada una de estas funciones se ejecuta una consulta sql y, como es una buena práctica, uso declaraciones preparadas (con parámetros con nombre).
Actualmente la conexión a la base de datos se establece en el constructor de la clase y también allí se preparan todas las sentencias. Pensé que sería una buena idea, por lo que las declaraciones están listas para su ejecución de inmediato.
Ahora me di cuenta de que mi caso de uso es a menudo crear un objeto db_connector, ejecutar una o quizás dos funciones y luego el ciclo de vida de los objetos termina y en un paso posterior se puede construir uno nuevo (o no). Por lo tanto, ya no estoy tan seguro de si es inteligente colocar las declaraciones preparadas en el constructor, ya que es previsible que terminaré con al menos 20 o probablemente más declaraciones preparadas.
Entonces mi pregunta es:
Esta respuesta se basa tanto en mi experiencia como en mi humilde opinión, pero intentaré elaborar mis argumentos para que no sea solo la opinión de un tipo al azar.
No creo que la conexión a la base de datos deba ser el objeto central de su aplicación, y mucho menos el único. Esperaría ver una clase completamente diferente para el usuario, por lo que luego puede tener más clases para todo lo demás. De lo contrario, su aplicación eventualmente consistirá en una sola clase en un archivo de 5000 líneas y su clase no será adecuada para rastrear datos de entidad a nivel de instancia y deberá pasar variables en llamadas de método. Eso es más o menos código de procedimiento en el vestido OOP.
Además, no creo que hacer que su clase de User herede de la base de Database (algo bastante frecuente, sin embargo) sea práctico en absoluto. Entrelazar la conexión de la base de datos y los objetos de la lógica empresarial no simplifica realmente el diseño de la aplicación y, de hecho, dificulta algunas partes.
El diseño de la capa de la base de datos en sí está bastante estandarizado:
Así es exactamente como funciona PDO.
Dado eso, es más fácil hacer que las clases de la base de datos sean solo una dependencia más de sus entidades en lugar de su abuelo. La inyección de esta dependencia se puede realizar por diferentes medios:
Conviértalo en una propiedad de clase:
public function __construct(\PDO $connection) { $this->connection = $connection; }Páselo a los métodos que realmente necesitaban (si no muchos de ellos):
public function getOrders(\PDO $connection) { $stmt = $connection->prepare('SELECT ...'); }... o use uno de esos elegantes contenedores de inyección de dependencia que puede encontrar en Packagist.
Tenga en cuenta que también hay mapeo relacional de objetos (ORM), patrón de registro activo ... Esas son familias de soluciones completamente diferentes que pueden satisfacer sus necesidades o no según su caso de uso, pero no lo que estoy describiendo aquí.
Dicho esto, se vuelve obvio que preparas las declaraciones en el punto exacto donde las necesitas. Este diseño ni siquiera permite lo contrario ;-)