2012-01-12 3 views
1

Как я могу устранить, чтобы написать $object = new Application_Model_Database() в каждом контроллере?Инициирование объектов в Zend Framework?

Например, для контроллера товаров я должен ввести $articles = new Application_Model_Articles() для каждого контроллера. Должен ли я разместить его под контроллером просмотра, помощниками действий или любым другим способом?

ответ

2

Ваш вопрос почти звучит как вопрос о наилучшей практике ООП, в отличие от конкретного вопроса Zend Framework. Независимо от того, использую ли я фреймворк, и независимо от того, какую структуру я выбираю, я основываюсь, когда и где я создаю новые объекты на тестируемости, сколько раз мне приходится писать $object = new My_Random_Object();.

Говоря конкретно о Zend Framework: Объекты, которые я буду использовать везде или почти везде, создадут в Bootstrap.php. Эти объекты обычно включают в себя адаптер базы данных, регистратор, объект просмотра и любые плагины, которые я могу использовать. Чтобы получить доступ к этим приложениям, я создам частные свойства в соответствующих контроллерах и назначу объекты этим свойствам в методе init() контроллера.

class ExampleController extends Zend_Controller_Action 
{ 

    public function init() 
    { 
     $bootstrap = $this->getInvokeArg('bootstrap'); 
     $this->_db = $bootstrap->getResource('db'); 
     $this->_log = $bootstrap->getResource('log'); 
     // and so on, and so forth 
    } 

} 

В идеале, модели, услуги, Даосы и т.д., все будет относительно плотно сгруппированных контроллером и действием. По моему опыту, и это говорит в целом, если у меня есть та же модель или класс обслуживания, которые отображаются во всех контроллерах в моем приложении, у меня проблема с организацией. При этом любая модель, которая появляется только в одном действии, создается в этом действии. Если это происходит через действия в контроллере, он создается в методе init() и присваивается свойству.Если он отображается на нескольких контроллерах, он создается в моем Bootstrap.php.

(В идеале, все создаётся в Bootstrap.php, поэтому вы можете поменять этот загрузочный лоток для тестирования. К сожалению, я не всегда это делаю, и я чаще всего использую принципы, изложенные выше.)

1

Ну, вам это действительно нужно в каждом контроллере? Потому что это в значительной степени по дизайну. Вы реализуете модели, когда они вам нужны. Это не так уж много кода.

Теперь, если его использовать во всей действия от контроллера вы могли бы всегда:

class MyController extends Zend_Controllers{ 
    $protected $_articleModel; 

...

и в конструкторе или функции __init() инициализирует его, так что вы можете использовать его в каждое действие через $this->_articleModel

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

public function __initModels(){ 
    $articles = new Application_Model_Articles() 
    Zend_Registry::set('articles', $articles); 
} 

И доступ к нему в контроллерах, как так:

Zend_Registry::get('articles')->fetchAll(); 

Но тогда ты еще написать пару символов.

Надеюсь, что эта помощь!

+0

Спасибо так много. Это действительно полезно. Я поставил неправильное слово. Предполагалось, что в каждом действии это не контроллер. Как я могу его начать? Большое спасибо. – Chveneburo

1

Если вы хотите использовать модели в контроллерах вы должны вызвать it..anyway некоторые ярлыки здесь

1.You может инициализировать его в разделе инициализации вашего контроллера как

public function init(){ 
    $this->object = new Application_Model_Database(); 
} 

Так что this->object доступен во всех действиях этого конкретного контроллера

2.Use Zend_Registry как предложено в ответе выше

+1

Одно небольшое редактирование: используйте '$ this-> object', а не просто' $ object'. – JamesG

+0

да @james sorry typo – coolguy

+0

Спасибо всем очень. Исправлена ​​проблема. – Chveneburo

1

Другая возможность заключается в использовании контейнера для инъекций зависимых, например, Symfony DI component. Он заботится о создании объектов, и вы получаете дополнительные преимущества:

  • Separation of concerns. У вас есть компонент, предназначенный для создания дерева объектов.
  • Простая возможность проверки объектов.
  • Последнее, но не менее важное: преимущества производительности, предоставляемые ленивым экземпляром (объекты создаются только тогда, когда вы их просите). Таким образом, если какой-либо объект не используется конкретным контроллером, обслуживающим ваш запрос, он не создается).

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

Надежда, что помогает,

0

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

//someControllerAction 
$object = new Application_Model_Articles(); 
$object->fetchAll(); 
//assign to view 
$this->view->articles = $object; 

вы могли бы быть лучше, если хелпер вид, похожий на:

//Articles.php put in /application/views/helpers 
class Zend_View_Helper_Articles extends Zend_View_Helper_Abstract { 

public function Articles() { 

$articles = new Application_Model_Articles(); 
$articles->fetchAll(); 
//return rowset object 
return $articles; 

Тогда на ваш взгляд (PHTML) вы могли бы сделать что-то вроде:

//someView.phmtl 
<?php $articles = $this->Articles(); ?> 
<h1><?php echo $this->escape($articles->title); ?></h1> 
<p><?php echo $this->escape($articles->body); ?></p> 

создание вспомогательного элемента просмотра позволяет полностью обходить контроллер, если вам просто нужно отображать данные из модели. Это очень простой пример и может использоваться с partials и partialLoops.
REF: ZF reference Custom View Helper
ZF partial view helper reference

+0

Hi RockyFord. Я ищу, чтобы разработчики фактически работали над проектом (оплачивали работу). Пожалуйста, дайте мне знать, если вы готовы. Поймайте меня на: keyne [at] veda.com.br –

Смежные вопросы