Domanda

Sto creando un ORM in PHP e ho una classe 'ORM' che fondamentalmente crea un oggetto corrispondente a una tabella di database (sto mirando a funzionalità simili / uguali a un pattern ActiveRecord.) ORM si estende 'Database', che imposta la connessione al database.

Quindi, posso chiamare:

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

La classe ORM fornisce questa funzionalità (imposta le proprietà della classe, fornisce i metodi save (), find (), findAll () ecc.) e il Cliente estende ORM. Tuttavia, in futuro potrei voler aggiungere metodi pubblici extra al Cliente (o qualsiasi altro modello che creo), quindi dovrebbe estendere ORM o no?

So di non aver fornito molte informazioni qui, ma spero che questo sia comprensibile su una vaga spiegazione, al contrario di pubblicare oltre 300 righe di codice.

È stato utile?

Soluzione

Sono d'accordo con le altre risposte qui - metti i metodi aggiuntivi in ??una classe discendente. Aggiungerei anche un asterisco a questo: ogni volta che estendi la classe con metodi extra, pensa a cosa stai cercando di ottenere con l'estensione e pensa se può essere generalizzato o tornare alla classe genitore . Ad esempio:

// 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
}

Altri suggerimenti

Stai certamente pensando correttamente di inserire la tua logica di business in una nuova classe al di fuori del tuo 'ORM'. Per me, invece di estendere semplicemente la classe ORM, preferirei incapsularla con una nuova classe di oggetti di valore per fornire un ulteriore grado di libertà dalla progettazione del database per liberarti dal pensare alla classe come un puro oggetto business.

No. Dovresti usare la composizione invece dell'eredità. Vedi il seguente esempio:

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

E ORM non dovrebbe estendere Database . Anche in questo caso la composizione è più adatta in questo caso d'uso.

Sì, colloca la tua logica aziendale in una classe discendente. Questo è un modello molto comune visto nella maggior parte dei framework di generazione dei livelli di accesso ai dati.

Devi assolutamente estendere la classe ORM. Cose diverse dovrebbero essere oggetti di classi diverse. I clienti sono molto diversi dai prodotti e supportare entrambi in una singola classe ORM sarebbe ingigantito e vanificherebbe completamente lo scopo di OOP.

Un'altra cosa interessante da fare è aggiungere hook per il salvataggio prima, dopo il salvataggio, ecc. Questi ti offrono maggiore flessibilità man mano che le tue classi di estensione ORM diventano più diverse.

Data la mia limitata conoscenza di PHP, non sono sicuro che ciò sia correlato, ma se stai cercando di creare molti oggetti business, potrebbe essere un processo incredibilmente dispendioso in termini di tempo. Forse dovresti considerare quadri come CakePHP e altri simili. Questo è bello se sei ancora in procinto di creare la tua logica aziendale.

Stai sicuramente pensando sulla retta via con l'eredità qui.

Se stai costruendo un ORM solo per il gusto di costruirne uno (o perché non ti piace il modo in cui gli altri gestiscono le cose) piuttosto che cercarlo, altrimenti potresti guardare un ORM precompilato che può generare la maggior parte del tuo codice direttamente dallo schema del database. Ti farà risparmiare un sacco di tempo. CoughPHP è attualmente il mio preferito.

L'ho risolto in questo modo nel mio Pork.dbObject . Assicurati di dare un'occhiata e afferrare un po 'del cervello che ho già fatto: 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"=>

L'ho risolto in questo modo nel mio Pork.dbObject . Assicurati di dare un'occhiata e afferrare un po 'del cervello che ho già fatto: P

<*>

Notare che in questo modo, qualsiasi database o funzionalità ORM viene sottratta all'oggetto Poll. Non serve sapere. Solo il database di installazione per collegare i campi / i mapping. e l'addRelation per collegare le relazioni con altri dbObjects.

Inoltre, anche la classe dbObject non sa molto di SQL. Le query di selezione / join sono create da un oggetto QueryBuilder speciale.

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

Notare che in questo modo, qualsiasi database o funzionalità ORM viene sottratta all'oggetto Poll. Non serve sapere. Solo il database di installazione per collegare i campi / i mapping. e l'addRelation per collegare le relazioni con altri dbObjects.

Inoltre, anche la classe dbObject non sa molto di SQL. Le query di selezione / join sono create da un oggetto QueryBuilder speciale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top