ここにいくつかの質問があるようです:
しかし、dbと対話する必要がなく、単純な関数だけが必要な場合は、その関数をモデルに配置する方がよいでしょうか。例:コントローラー:
public function printAction() {
$data = $this->getRequest()->getPost();
$label = "blablabla";
$this->view->label = $label;
}
まず、Zend Frameworkのコンテキストでは、この特定の例はあまり意味がありません。コントローラの要点は、ビューテンプレートにデータを入力することです。しかし、私はその考えを理解しています。あなたの懸念に対処する手段として、アクションヘルパーとビューヘルパーを紹介します。他のどこにも適合しないように見えるコードの部分については、いつでもライブラリにユーティリティクラスを追加できます。
アクションヘルパーは通常、反復的または再利用可能なコントローラーコードをカプセル化するために使用されます。それらは必要に応じて単純または複雑にすることができます。ここに簡単な例を示します。
class Controller_Action_Helper_Login extends Zend_Controller_Action_Helper_Abstract
{
/**
* @return \Application_Form_Login
*/
public function direct()
{
$form = new Application_Form_Login();
$form->setAction('/index/login');
return $form;
}
}
//add the helper path to the stack in the application.ini
resources.frontController.actionhelperpaths.Controller_Action_Helper = APPLICATION_PATH "/../library/Controller/Action/Helper"
//the helper is called in the controller
$this->_helper->login();
ビューヘルパーは、ビューテンプレートに対して同じことを行います。
class Zend_View_Helper_PadId extends Zend_View_Helper_Abstract
{
/**
* add leading zeros to value
* @param type $id
* @return string
*/
public function padId($id)
{
return str_pad($id, 5, 0, STR_PAD_LEFT);
}
}
//in this example the helper path is added to the stack from the boostrap.php
protected function _initView()
{
//Initialize view
$view = new Zend_View();
//add custom view helper path
$view->addHelperPath('/../library/View/Helper');
//truncated for brevity
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper(
'ViewRenderer');
$viewRenderer->setView($view);
//Return it, so that it can be stored by the bootstrap
return $view;
}
//and to use the helper in the view template
//any.phtml
<?php echo $this->padId($this->id) ?>
モデルとは異なる結果が必要ですが、1回の呼び出しですべての作業をモデル化するか、さらに呼び出しを行って結果を収集し、テーブルが結合されていない場合やiテーブルから1つの行をフェッチし、他の行とは異なる行をフェッチする必要があります。
この質問は、正確さよりも構造に関するものです。
必要に応じて、アクションヘルパーとビューヘルパーでデータベーステーブルモデルを操作して、単純な/反復的なクエリを実行できますが、ほとんどの開発者は、このアプローチを維持するのが難しいか、単に醜いものとして眉をひそめる可能性があります。
多くの人は、データベースのニーズを管理するためにDoctrineまたはPropelを好むようです。
この時点で、私は自分自身をロールバックするのが好きで、現在はドメインモデルとデータマッパーを好みます。すべてがすべてのパターンであるとは限りませんが、あなたの質問には適切であるようです。
これは、初めて実装するための簡単な提案ではありませんが、開始するのに役立つ2つの記事が見つかりました。
http://phpmaster.com/building-a-domain-model/
http://phpmaster.com/integrating-the-data-mappers/
そして、あなたが本当にそれに参加したいのなら、試してみてください:
http://survivethedeepend.com/
これがあなたの質問の少なくとも一部に答えることを願っています。