#zend-framework #model
#zend-framework #Модель
Вопрос:
Из документации здесь:http://framework.zend.com/manual/en/learning.quickstart.create-model.html
Мы можем видеть:
// application/models/Guestbook.php
class Application_Model_Guestbook
{
protected $_comment;
protected $_created;
protected $_email;
protected $_id;
public function __construct(array $options = null)
{
if (is_array($options)) {
$this->setOptions($options);
}
}
public function __set($name, $value)
{
$method = 'set' . $name;
if (('mapper' == $name) || !method_exists($this, $method)) {
throw new Exception('Invalid guestbook property');
}
$this->$method($value);
}
public function __get($name)
{
$method = 'get' . $name;
if (('mapper' == $name) || !method_exists($this, $method)) {
throw new Exception('Invalid guestbook property');
}
return $this->$method();
}
public function setOptions(array $options)
{
$methods = get_class_methods($this);
foreach ($options as $key => $value) {
$method = 'set' . ucfirst($key);
if (in_array($method, $methods)) {
$this->$method($value);
}
}
return $this;
}
... following getters and setters...
Я не понимаю, и это не объяснено (возможно, потому, что это слишком просто), что он делает, и зачем нам нужен метод setOptions?
Я пытаюсь следовать этому руководству, но я не могу слепо вставлять код, не зная причины его существования. Я буду доволен моделью, содержащей только методы получения и установки, но, возможно, все это не сработает, если я не буду использовать этот метод setOptions. Я обеспокоен, потому что я вижу это в конструкторе, так что, должно быть, это как-то важно.
Кто-нибудь может мне помочь разобраться, действительно ли нам это нужно, и если да, то что это значит?
Заранее спасибо.
Ответ №1:
Это просто шаблон, используемый различными компонентами ZF.
Вы можете предоставить конфигурационный массив (параметры) для конструктора для многих компонентов. Обычно API для таких настраиваемых компонентов включает метод setOptions, подобный тому, который вы видите там.
Это всего лишь руководство по быстрому запуску. Лично я ему не следую, поскольку считаю, что модели должны соответствовать интерфейсу, более специфичному для задачи / домена — например, на мой взгляд, модель гостевой книги должна принимать только определенные параметры в конструкторе, такие как владелец гостевой книги или тому подобное, и не допускать «общего» списка опций.
Комментарии:
1. Итак, мы вполне можем отказаться от этого метода, не затрагивая шлюз данных и средство отображения данных, которые они используют, да?
2. Я не очень знаком с вещами, связанными с Zend_Db, но я подозреваю, что он использует отражение или что-то еще, поэтому это не помешает ему.
Ответ №2:
ИМО, хорошей практикой является создание такого метода, потому что вы, скорее всего, получите «массив вещей» (скажем … из формы), а не дискретные переменные. И ИМО лучше и удобочитаем в использовании
$this->setOption($form->getValues());
затем вызывайте его один за другим
$data = $form->getValues();
$this->setName($data['name']);
$this->setSurname($data['surname']);
// ....
Но этот метод должен быть расположен в каком-нибудь родительском классе, который расширен Application_Model_Guestbook
, который, как я полагаю, был вне области действия guickstart. Также может быть хорошей практикой выдавать какое-либо уведомление, когда в параметре array отсутствует параметр setter.