Должен ли я расширить этот класс? (PHP)

Question

Я создаю ORM в PHP, и у меня есть класс 'ORM', который в основном создает объект, соответствующий таблице базы данных (я стремлюсь к / аналогичной функциональности, что и шаблон ActiveRecord.) ORM Сам расширяет «База данных», которая устанавливает соединение с базой данных.

Итак, я могу позвонить: $c = new Customer(); $c->name = 'John Smith'; $c->save();

Класс ORM предоставляет эту функциональность (устанавливает свойства класса, предоставляет методы save (), find (), findAll () и т. Д.), А Customer расширяет ORM. Однако в будущем я, возможно, захочу добавить дополнительные общедоступные методы для Customer (или любой другой модели, которую я создаю), поэтому должно ли это быть расширение ORM или нет?

Я знаю, что не предоставил здесь много информации, но, надеюсь, это понятно из расплывчатого объяснения, в отличие от размещения более 300 строк кода.

Answer 1

Я согласен с другими ответами здесь - поместите дополнительные методы в класс-потомок. Я бы также добавил к этому звездочку: каждый раз, когда вы расширяете класс дополнительными методами, подумайте о том, чего вы пытаетесь достичь с помощью расширения, и подумайте, можно ли его обобщить и вернуть обратно в родительский класс. , Например:

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

Неа. Вы должны использовать композицию вместо наследования. Смотрите следующий пример:

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

И ORM класс не должен расширяться Database. Композиция снова лучше всего подходит в этом случае использования.

Answer 3

Вы, конечно, правильно думаете, чтобы поместить свою бизнес-логику в новый класс за пределами вашего «ORM». Для меня, вместо того, чтобы просто расширять ORM-класс, я бы предпочел инкапсулировать его с новым, ценным классом объектов, чтобы обеспечить дополнительную степень свободы от вашего дизайна базы данных, чтобы вы могли думать о классе как о чистом бизнес-объекте.

Answer 4

Да, поместите свою бизнес-логику в класс-потомок. Это очень распространенная модель, наблюдаемая в большинстве структур создания уровней доступа к данным.

Answer 5

Вы определенно думаете по правильному пути с наследованием здесь.

Если вы строите ORM просто ради его создания (или потому, что вам не нравится, как другие обрабатывают вещи), чем идти на это, в противном случае вы можете взглянуть на готовый ORM, который может генерировать большую часть ваших код прямо из вашей схемы базы данных. Это сэкономит вам время. CoughPHP в настоящее время мой любимый.

Answer 6

Я решил это так в моем Pork.dbObject . Убедитесь, что проверили это и поймали некоторые из мозговых переживаний, которые я уже сделал: 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
}

Обратите внимание, что таким образом любая функция базы данных или ORM абстрагируется от объекта Poll. не нужно , чтобы знать. Просто база данных для подключения полей / отображений. и addRelation, чтобы связать отношения с другими объектами dbObject.

Кроме того, даже класс dbObject мало что знает о SQL. Запросы выбора / объединения строятся с помощью специального объекта QueryBuilder.

Answer 7

Учитывая мои ограниченные знания PHP, я не уверен, связано ли это с этим, но если вы пытаетесь создать много бизнес-объектов, это может быть невероятно длительным процессом. Возможно, вам следует рассмотреть такие фреймворки, как CakePHP и другие подобные. Это хорошо, если вы все еще находитесь в процессе создания своей бизнес-логики.

Answer 8

Вы должны обязательно расширить класс ORM. Разные вещи должны быть объектами разных классов. Клиенты сильно отличаются от Продуктов, и поддержка обоих в одном классе ORM была бы ненужной раздувкой и полностью противоречила бы цели ООП.

Еще одна приятная вещь, которую нужно сделать, - это добавить хуки для сохранения перед сохранением, после сохранения и т. Д. Это дает вам больше гибкости, поскольку ваши расширяющие классы ORM становятся более разнообразными.