Модели Zend_DB и MVC, соответствующие таблицам базы данных - PullRequest
Новая
       27

Модели Zend_DB и MVC, соответствующие таблицам базы данных

1 голос
/ 22 октября 2011

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

Итак, Билл Карвин говорил, что Model 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();

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

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

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

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

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

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

Спасибо: D Dom

1 Ответ

3 голосов
/ 22 октября 2011

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

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

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

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

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

...