我的 MVC 控制器应该是面向对象的吗？
我正在制作一个 Perl 网站，我将使用 Template Toolkit（用于视图）、一大堆用于数据库交互和业务逻辑（模型）的对象，但我想知道：控制器应该是 OO 的吗？
我觉得他们应该这样做，只是为了保持一致性，但当我不以面向对象的方式与控制器交互时，我也觉得这可能有点多余。控制器的调用更多是一种“即发即忘”的方式。
感谢您的任何想法。
I'm making a Perl website, and I'll using Template Toolkit (for the view), a whole bunch of objects for DB interaction and business logic (the model), but I'm wondering: should the controllers be OO?
I feel like they should, just for consistency, but it also feels it might be a bit redundant when I'm not interacting with the controllers in an OO way. The controllers are called more in a fire-and-forget kind of way.
Thanks for any thoughts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，使控制器面向对象。您应该将它们作为对象进行交互。您可能希望稍后使用子类来扩展或修改它们。许多人因为认为自己只需要一个控制器而陷入麻烦，因此他们因不规划未来的灵活性而将自己陷入困境。
Yes, make the controllers object-oriented. You should be interacting with them as objects. You might want to extend or modify them later with subclasses. A lot of people get themselves into trouble by assuming that they'll ever only need one controller, so they paint themselves into a corner by not planning for future flexibility.
在我看来，如果感觉多余，就不应该使用它。
如果您在不需要它的项目上使用 OOP，那么 OOP 的弊大于利。
如果只是为了一致性，就放弃它。有很多人（例如）在 c++ 中使用 stl，但以过程方式编写其余代码。如果您觉得 OOP 势不可挡，请选择您正在考虑使用的混合方法（需要时采用 OOP，其余部分进行过程），只要您的代码不会因此而变得难以阅读。
In my opinion, if it feels reduntant, you shouldn't use it.
OOP can have more cons than pros if you use it on a project that doesn't need it.
If it's just about consistency just drop it. there's plenty of people that (for example) in c++ use stl but write the rest of the code in a procedural way. If you feel OOP overwhelming go for the mixed approach you are thinking of using (OOP where needed, procedura the rest), as long as your code doesn't become difficult to read because of this.
您需要查看 Catalyst，这将为您省去很多担心使用什么 OO 作为控制器以及如何实现它。它并不完美，但如果你愿意的话，它是设计荒野中的一条人迹罕至的道路。
You need to look at Catalyst, which will save you a good deal of worry about what OO to use for controllers and how to implement it. It's not perfect but, if you like, it's a well beaten path through the design wilderness.