TTテンプレートで使用している条件と計算が多すぎると思います。
DBIcからのアイテムの結果セットを表示しています。アイテムごとに、取得した値を使用して計算する必要がありますが、テンプレートが適切な場所ではないようです。
しかし、Catalystでは、DBIcに由来する厚いオブジェクトです。
では、どうすればロジックをモデルに移動できますか?すべてのアイテムに対してループ全体を実行し、オブジェクトを何らかの方法で変更する必要がありますか?
よろしく:Migue、
TTテンプレートで使用している条件と計算が多すぎると思います。
DBIcからのアイテムの結果セットを表示しています。アイテムごとに、取得した値を使用して計算する必要がありますが、テンプレートが適切な場所ではないようです。
しかし、Catalystでは、DBIcに由来する厚いオブジェクトです。
では、どうすればロジックをモデルに移動できますか?すべてのアイテムに対してループ全体を実行し、オブジェクトを何らかの方法で変更する必要がありますか?
よろしく:Migue、
まず、懸念事項を適切に分離することで、正しい方向に進んでいます。6 ~ 12 か月後にメンテナになった場合は、感謝することでしょう。
IMHO、Catalystコントローラーは、さまざまなモデルのビジネスロジックでできるだけ薄くする必要があります。これにより、処理する Catalyst のオーバーヘッドがないため、テストが容易になります。私自身、モデル分離についてかなり考えてきました。私が遭遇した2つの考え方があります:
1) DBIx::Class Result クラスにビジネスロジックを持たせます。このアプローチは便利で簡単です。
2) コントローラによってインスタンス化され、DBIx::Class スキーマ オブジェクトを持つスタンドアロン モデルを作成します。モデルは DBIC スキーマを使用してデータベースにクエリを実行し、結果のデータを独自のビジネス ロジック メソッドで使用します。DB アクセスをビジネス ロジックから分離するため、多くのビジネス ロジックがある場合は、このアプローチが適している可能性があります。
個人的には、歴史的にアプローチ 1 を使用してきましたが、より大きなアプリでは 2 に傾いています。
2 つの可能性。
対応するスキーマ クラスにメソッドを作成します。
(1 が不可能な場合) このオブジェクトを引数として持つテンプレートにコールバックを渡します。
あなたは出来る
私は個人的に2番目のものを好みます。それがお役に立てば幸いです。