将逻辑从模板工具包转移到 Catalyst
我认为我在 TT 模板中使用了太多的条件和计算。
我正在显示 DBIc 的项目结果集。对于每个项目，我需要使用检索到的值来计算内容，而模板似乎不是正确的位置。
但在 Catalyst 中，它是来自 DBIc 的厚对象。
那么如何将逻辑转移到模型中呢？我必须对所有项目运行整个循环并以某种方式更改对象吗？
问候： 米格，
I think that I am using too much conditionals and calculations in the TT templates.
I am displaying a result set of items from DBIc. For each item I need to calculate things using the retrieved values, and the template doesn't seems to be the right place.
But in Catalyst it is a thick object that comes from DBIc.
So how can I move logic to the model? Must I run a whole loop for all items and change the object somehow?
Regards:
Migue,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，你想要正确地分离关注点，这是正确的轨道。如果您是 6-12 个月后的维护者，您会感谢自己。
恕我直言，您的 Catalyst 控制器应该尽可能精简，并包含各种模型中的业务逻辑。这使得测试变得更容易，因为您无需处理 Catalyst 的开销。我自己也一直在思考模型分离的问题。我遇到过两种思想流派：
1) 让您的 DBIx::Class Result 类具有业务逻辑。这种方法既方便又简单。
2) 创建一个由控制器实例化的独立模型，该模型具有 DBIx::Class 模式对象。该模型将使用 DBIC 模式来查询数据库，然后在其自己的业务逻辑方法中使用结果数据。如果您有大量业务逻辑，那么这种方法可能会更好，因为您将数据库访问与业务逻辑分开。
就我个人而言，我过去一直使用方法 #1，但对于大型应用程序，我倾向于使用方法 #2。
First, you're on the right track by wanting to properly separate concerns. You'll thank yourself if you're the maintainer 6-12 months down the road.
IMHO, your Catalyst controllers should be as thin as possible with the business logic in the various models. This makes it easier to test because you don't have the overhead of Catalyst to deal with. I've been thinking about model separation quite a bit myself. There are two schools of thought I've come across:
1) Make your DBIx::Class Result classes have the business logic. This approach is convenient and simple.
2) Make a standalone Model which is instantiated by the Controller, and which has a DBIx::Class schema object. The model would use the DBIC schema to query the database, and then use the resulting data in its own business logic methods. This approach might be better if you have a lot of business logic since you separate DB access from business logic.
Personally, I've historically used approach #1 but I'm leaning towards #2 for larger apps.
两种可能性。
在相应的模式类中创建一个方法。
（如果 1 不可能）将回调传递给将此对象作为参数的模板。
Two possibilities.
Create a method in corresponding schema class.
(if 1 is not possible) Pass a callback to template that would have this object as argument.
您可以
我个人更喜欢第二个。
我希望这有帮助。
You could
I personally would prefer the second one.
I hope that helps.