Devrais-je prolonger cette classe? (PHP)

Question

Je crée un ORM en PHP et j'ai une classe 'ORM' qui crée en gros un objet correspondant à une table de base de données (je vise une fonctionnalité similaire / identique à celle d'un modèle ActiveRecord.) ORM lui-même étend 'Base de données', qui établit la connexion à la base de données.

Je peux donc appeler:

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

La classe ORM fournit cette fonctionnalité (définit les propriétés de la classe, fournit les méthodes save (), find (), findAll (), etc.) et le client étend ORM. Cependant, à l'avenir, je souhaiterai peut-être ajouter des méthodes publiques supplémentaires à Customer (ou à tout autre modèle que je crée). Par conséquent, cela devrait-il être une extension ORM ou pas?

Je sais que je n'ai pas fourni beaucoup d'informations ici, mais j'espère que cela est compréhensible sur une explication vague, par opposition à la publication de plus de 300 lignes de code.

Answer 1

Je suis d’accord avec les autres réponses ici: mettez les méthodes supplémentaires dans une classe de descendants. J'ajouterais aussi un astérisque à cela: chaque fois que vous étendez la classe avec des méthodes supplémentaires, réfléchissez à ce que vous essayez d'atteindre avec l'extension, et demandez-vous si elle peut être généralisée et intégrée dans la classe parente . Par exemple:

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

Answer 2

Vous envisagez certainement de placer votre logique métier dans une nouvelle classe en dehors de votre "ORM". Pour moi, au lieu d'étendre simplement la classe ORM, je préfèrerais l'encapsuler avec une nouvelle classe d'objets de valeur pour offrir un degré supplémentaire de liberté par rapport à la conception de votre base de données afin de vous permettre de la considérer comme un objet métier pur.

Answer 3

Nope. Vous devriez utiliser la composition au lieu de l'héritage. Voir l'exemple suivant:

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

Et la classe ORM ne doit pas être étendue à Database . La composition est de nouveau appropriée dans ce cas d'utilisation.

Answer 4

Oui, placez votre logique métier dans une classe descendante. Ceci est un modèle très courant observé dans la plupart des frameworks de génération de couches d'accès aux données.

Answer 5

Vous devez absolument étendre la classe ORM. Différentes choses devraient être des objets de différentes classes. Les clients sont très différents des produits et prendre en charge les deux systèmes dans une seule classe ORM constituerait un fardeau inutile et irait à l’encontre du but de la programmation orientée objet.

Une autre bonne chose à faire est d’ajouter des crochets pour, avant, après, etc., ce qui vous donne plus de flexibilité lorsque vos classes ORM sont de plus en plus diversifiées.

Answer 6

Étant donné ma connaissance limitée de PHP, je ne sais pas si cela est lié, mais si vous essayez de créer de nombreux objets métier, le processus peut prendre énormément de temps. Vous devriez peut-être envisager des cadres tels que CakePHP et d'autres outils similaires. C’est bien si vous êtes toujours en train de créer votre logique d’entreprise.

Answer 7

Vous pensez vraiment aller dans le bon sens avec l'héritage ici.

Si vous construisez un ORM juste pour le construire (ou parce que vous n'aimez pas la façon dont les autres traitent les choses), vous pouvez regarder un ORM pré-construit qui peut générer la plupart de vos code directement à partir de votre schéma de base de données. Cela vous fera gagner beaucoup de temps. CoughPHP est actuellement mon préféré.

Answer 8

Je l'ai résolu comme suit dans mon Pork.dbObject . Assurez-vous de vérifier et de décrocher une partie de la réflexion que j'ai déjà fait: 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"=>
 Je l'ai résolu comme suit dans mon  Pork.dbObject . Assurez-vous de vérifier et de décrocher une partie de la réflexion que j'ai déjà fait: P 

<*>

 Notez que de cette manière, toute base de données ou fonctionnalité ORM est extraite de l'objet Poll. Il n'a pas besoin de  savoir . Juste la base de données setup pour connecter les champs / mappages. et addRelation pour relier les relations aux autres dbObjects. 

 De même, même la classe dbObject ne connaît pas grand chose à propos de SQL. Les requêtes de sélection / jointure sont générées par un objet QueryBuilder spécial. 
SERVER['REMOTE_ADDR'])); // find all votes for current ip
}

Notez que de cette manière, toute base de données ou fonctionnalité ORM est extraite de l'objet Poll. Il n'a pas besoin de savoir . Juste la base de données setup pour connecter les champs / mappages. et addRelation pour relier les relations aux autres dbObjects.

De même, même la classe dbObject ne connaît pas grand chose à propos de SQL. Les requêtes de sélection / jointure sont générées par un objet QueryBuilder spécial.