Pregunta

Estoy creando un ORM en PHP, y tengo una clase 'ORM' que básicamente crea un objeto correspondiente a una tabla de base de datos (mi objetivo es similar a / la misma funcionalidad que un patrón ActiveRecord). ORM en sí extiende la 'Base de datos', que configura la conexión de la base de datos.

Por lo tanto, puedo llamar:

$c = new Customer();
$c->name = 'John Smith';
$c->save();

La clase ORM proporciona esta funcionalidad (configura las propiedades de la clase, proporciona los métodos save (), find (), findAll () etc.) y el Cliente extiende ORM. Sin embargo, en el futuro es posible que desee agregar métodos públicos adicionales al Cliente (o a cualquier otro modelo que cree), ¿debería esto extender ORM o no?

Sé que no he proporcionado mucha información aquí, pero espero que esto sea comprensible en una explicación vaga, en lugar de publicar más de 300 líneas de código.

¿Fue útil?

Solución

Estoy de acuerdo con las otras respuestas aquí: coloque los métodos adicionales en una clase descendiente. Sin embargo, también agregaría un asterisco a eso: cada vez que extienda la clase con métodos adicionales, piense en lo que está tratando de lograr con la extensión y piense si se puede generalizar y volver a incluir en la clase principal . Por ejemplo:

// Customer.class.php
function getByName($name) {
    // SELECT * FROM `customer` WHERE `name` = $name
}

// ** this could instead be written as: **
// ORM.class.php
function getByField($field, $value) {
    // SELECT * FROM `$this->table` WHERE `$field` = $value
}

Otros consejos

Ciertamente, está pensando correctamente en poner su lógica empresarial en una nueva clase fuera de su 'ORM'. Para mí, en lugar de simplemente extender la clase ORM, prefiero encapsularla con una nueva clase de objeto de valor para proporcionar un grado adicional de libertad respecto del diseño de su base de datos para liberarlo de pensar que la clase es un objeto comercial puro.

No. Deberías usar la composición en lugar de la herencia. Vea el siguiente ejemplo:

class Customer {
    public $name;
    public function save() {
        $orm = new ORM('customers', 'id'); // table name and primary key
        $orm->name = $this->name;
        $orm->save();
    }
}
La clase

y ORM no debe extender Database . La composición nuevamente es más adecuada en este caso de uso.

Sí, coloca tu lógica de negocios en una clase descendiente. Este es un patrón muy común que se ve en la mayoría de los marcos de generación de capas de acceso a datos.

Absolutamente debe extender la clase ORM. Diferentes cosas deben ser objetos de diferentes clases. Los clientes son muy diferentes de los Productos, y dar soporte a ambos en una sola clase de ORM sería una hinchazón innecesaria y anularía completamente el propósito de la POO.

Otra cosa buena que hacer es agregar ganchos para guardar antes, después de guardar, etc. Esto te da más flexibilidad a medida que tus clases de extensión ORM se vuelven más diversas.

Dado mi limitado conocimiento de PHP, no estoy seguro de si esto está relacionado, pero si está intentando crear muchos objetos comerciales, este podría ser un proceso increíblemente lento. Tal vez debería considerar marcos como CakePHP y otros similares. Esto es bueno si aún está en el proceso de crear su lógica empresarial.

Definitivamente estás pensando en la línea correcta con herencia aquí.

Si está creando un ORM solo por el hecho de construir uno (o porque no le gusta la forma en que los demás manejan las cosas) de lo contrario, de lo contrario, puede buscar un ORM precompilado que pueda generar la mayoría de sus código directamente desde el esquema de su base de datos. Te ahorrará grandes cantidades de tiempo. CoughPHP es actualmente mi favorito.

Lo he resuelto así en mi Pork.dbObject . Asegúrate de comprobarlo y obtener algunos de los problemas que ya hice: P

class Poll extends dbObject // dbObject is my ORM. Poll can extend it so it gets all properties.
{
        function __construct($ID=false)
        {
            $this->__setupDatabase('polls', // db table
                array('ID_Poll' => 'ID',    // db field => object property
                        'strPollQuestion' => 'strpollquestion', 
                        'datPublished' => 'datpublished', 
                        'datCloseDate' => 'datclosedate', 
                        'enmClosed' => 'enmclosed', 
                        'enmGoedgekeurd' => 'enmgoedgekeurd'),
                        'ID_Poll',  // primary db key 
                        $ID);   // primary key value
        $this->addRelation('Pollitem'); //Connect PollItem to Poll 1;1
        $this->addRelation('Pollvote', 'PollUser'); // connect pollVote via PollUser (many:many)


        }

function Display()
{

 // do your displayíng for poll here:
    $pollItems = $this->Find("PollItem"); // find all poll items
    $alreadyvoted = $this->Find("PollVote", array("IP"=>

Lo he resuelto así en mi Pork.dbObject . Asegúrate de comprobarlo y obtener algunos de los problemas que ya hice: P

<*>

Tenga en cuenta que de esta manera, cualquier base de datos u funcionalidad ORM se extrae del objeto Poll. No necesita saber. Solo la base de datos de configuración para conectar los campos / asignaciones. y el addRelation para conectar las relaciones a otros dbObjects.

Además, incluso la clase dbObject no sabe mucho sobre SQL. Las consultas de selección / unión se crean mediante un objeto especial QueryBuilder.

SERVER['REMOTE_ADDR'])); // find all votes for current ip }

Tenga en cuenta que de esta manera, cualquier base de datos u funcionalidad ORM se extrae del objeto Poll. No necesita saber. Solo la base de datos de configuración para conectar los campos / asignaciones. y el addRelation para conectar las relaciones a otros dbObjects.

Además, incluso la clase dbObject no sabe mucho sobre SQL. Las consultas de selección / unión se crean mediante un objeto especial QueryBuilder.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top