Блог

Я читал кое-что от Билла Карвина (создателя Zend_Db) о моделях, не имеющих прямого отношения к таблицам базы данных. (Я думаю, что некоторые разработчики имеют в своих моделях прямое расширение Zend_tables или около того, что затрудняет добавление кэширования объектов в memcached, что имеет смысл.)

Итак, Билл Карвин говорил, что has таблицы моделей и isn't a таблицы, но я все еще думаю, что то, как у меня это есть, правильно, поскольку оно разработано объектно-ориентированным образом.

Например (просто пример):

 A Monster has 1:M Mouth. a Mouth has 1:M Tooth. 
 

Итак, в моей базе данных у меня было бы 5 таблиц:

 Monster: id, name, type
MonsterMouth: id, monster_id, mouth_id
Mouth: id, size
MouthTeeth: id, mouth_id, tooth_id
Tooth: id, size, shape, sharpness
 

Затем 3 класса:

 class Model_Monster { 
    private $id, $name, $type, $mouths = array();
    public function __construct ($id) {
        // Set properties from DB for supplied ID
        // Go through DB and add the mouths based on monster ID
    }

    public function countTeeth () {
        // Loop through each $mouths as $mouth and call $mouth->getTotalTeeth();
    }
} 
class Model_MonsterMouth { 
    private $id, $size, $teeth = array(); 
    public function __construct($id) {
        // Set properties from DB for supplied ID
        // Go through DB and add the types of teeth for this mouth ID
    }

    public function getTotalTeeth () {
        // return sizeof($teeth);
    }

}
class Model_Tooth {
    private $id, $size, $shape, $sharpness;
    public function __construct($id) {
        // Populate details based on ID passed
    }
}
 

Тогда я предполагаю методы подсчета зубов и прочее…

 $monsterId = 1;
$monster = new Monster($monsterId);
// Count total teeth
$totalTeeth = $monster->countTeeth();
 

Таким образом, у монстра может быть много разных ртов, а у 1 рта может быть много разных типов зубов.

После написания этого длинного поста я думаю, что я все понял правильно, и это Bill Karwin говорит о тех, у кого есть 5 Models , а не 3 …

У меня есть 5 Tables , но только 3 Models в виде двух таблиц для решения отношений M: M таблиц.

2 of the 3 Models используйте композицию для хранения многих объектов другого типа.

Если бы у монстра было 10 ртов от 9 до 10 тысяч примерно с 10 различными типами зубов… будет ли это проблемой производительности? Я имею в виду, будет ли PHP видеть это как: a,a,a,a,a,b,b или 5*a and 2*b . Если наличие объекта размером от 1 до 100 КБ и итеративное добавление их в составной элемент происходит медленно, то, я думаю, у меня должно быть только одно его появление со свойством number, чтобы указать, сколько существует такого типа.

Если я все правильно понял, возможно, это может помочь некоторым другим парням, у которых возникли проблемы с этим.

Спасибо: D Dom

Не желая вкладывать слова в уста Билла Ящерицы, я думаю, что вместо «Многие ко многим» он больше говорит о том факте, что вы должны отделять свою абстрактную концепцию бизнес-модели от лежащего в ее основе представления.

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

Подумайте также, если ваша модель хотела использовать поле типа «Полное имя», которое представляло собой простое объединение «FirstName» и «Фамилия». Возможно, вы действительно не захотите хранить «полное имя» вместе с «FirstName» и «Фамилия» в базе данных, потому что это дублирующие данные и больше работы для обновления, но если ваша модель очень тесно связана с базовым представлением, вам нужно либо а) добавить «полное имя» вваша база данных или б) работает без «полного имени» в вашей модели.

Сохраняя четкое разделение, вы сможете иметь «Полное имя» в своей модели и некоторый фрагмент кода, который его сгенерировал, имея при этом только «Имя» и «Фамилию» в базе данных. Конечно, это также значительно упрощает переключение внутренней технологии базы данных, если вам когда-нибудь понадобится.

С моей точки зрения, ключевым моментом является то, что модель — это не только поля, которые она содержит, но и бизнес-правила, проверка и, возможно, действия, которые вы можете выполнять с ней. Таблица — это просто удобное место для хранения полей, необходимых для поддержки такого поведения.