Pergunta

Estou criando um ORM em PHP, e eu tenho uma classe 'ORM' que basicamente cria um objeto correspondente a uma tabela de banco de dados (estou apontando para uma funcionalidade semelhante ao / mesmo que um padrão de ActiveRecord.) ORM se estende 'database', que estabelece a conexão banco de dados.

Então, eu posso chamar:

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

A classe ORM fornece esta funcionalidade (configura as propriedades da classe, fornece save (), find (), findAll (), etc. métodos) e Cliente estende ORM. No entanto, no futuro eu possa estar querendo adicionar métodos adicionais públicas ao Cliente (ou qualquer outro modelo crio), então isso deve ser estendendo ORM ou não?

Eu sei que eu não forneceram muita informação aqui, mas espero que isso é compreensível em uma explicação vaga, ao contrário de postar-se mais de 300 linhas de código.

Foi útil?

Solução

Concordo com as outras respostas aqui - colocar os métodos adicionais em uma classe descendente. Eu também gostaria de acrescentar um asterisco para que embora: cada vez que você estender a classe com métodos extra, pense no que você está tentando alcançar com a extensão, e pensar sobre se é ou não pode ser generalizada e trabalhou volta para a classe pai . Por exemplo:

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

Outras dicas

Você está certamente a pensar corretamente para colocar a sua lógica de negócios em uma nova classe fora de sua 'ORM'. Para mim, em vez de simplesmente estender o ORM de classe, prefiro encapsulá-lo com uma classe de objeto novo, valor para fornecer um grau adicional de liberdade do seu projeto de banco de dados para libertar-se de pensar da classe como um objeto de negócios pura.

Não. Você deve usar a composição em vez de herança. Veja o seguinte exemplo:

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

E ORM não deve se estender Database. Composição de novo é mais adequado neste caso de uso.

Sim, colocar sua lógica de negócio em uma classe descendente. Este é um padrão muito comum visto na maioria das estruturas de geração de camadas de acesso de dados.

Você deve absolutamente estender a classe ORM. Diferentes coisas devem ser objetos de diferentes classes. Os clientes são muito diferentes dos produtos, e para apoiar tanto em uma única classe ORM seria inchaço desnecessário e completamente derrotar o propósito de OOP.

Outra coisa legal de se fazer é adicionar ganchos para antes de salvar, após salvar, etc. Estes dão-lhe mais flexibilidade como seu ORM estender classes se tornam mais diversificadas.

Dado o meu conhecimento limitado de PHP eu não tenho certeza se isso está relacionado, mas se você está tentando criar muitos objetos de negócios este pode ser um processo extremamente demorado. Talvez você deve considerar estruturas como CakePHP e outros como ele. Isso é bom se você ainda está no processo de criação de sua lógica de negócios.

Você está definitivamente pensando no caminho certo com herança aqui.

Se você está construindo um ORM apenas por uma questão de construção de um (ou porque você não gosta da maneira como os outros lidar com as coisas) do que ir para ele, caso contrário você pode olhar para um ORM pré-construídos que podem gerar maior parte do seu código diretamente do seu banco de dados esquema. Vai poupar carradas de tempo. CoughPHP é atualmente o meu favorito.

Eu ter resolvido-lo como este em minha Pork.dbObject . Certifique-se de verificá-la e prender alguns dos braincrunching eu já fiz: 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"=>$_SERVER['REMOTE_ADDR'])); // find all votes for current ip
}

Note que desta forma, qualquer funcionalidade de banco de dados ou ORM é captada longe do objeto Poll. Não necessidade para saber. Apenas o SetupDatabase para ligar os campos / mapeamentos. eo addRelation para ligar as relações com outras DBObjects.

Além disso, mesmo a classe DBOBJECT não sabe muito sobre SQL. Selecione / associar-se as consultas são construídas por um objeto QueryBuilder especial.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top