根据行动改变观点是不好的做法吗?
我有一个控制器索引,它管理多个非专业信息页面(例如主页、概述、功能等)。每个页面在控制器中都有自己的操作。根据操作的不同,使用不同的视图脚本来呈现内容。
使用不同的视图脚本来呈现每个操作是不好的做法吗?每个页面都应该有自己的控制器吗?谢谢,
I have a single controller, Index, that manages several non-specialized informational pages (e.g Homepage, Overview, Features, etc.). Each page has its own action in the controller. Depending on the action, a different View script is used to render the content.
Is it bad practice to use different View scripts to render each action? Should each page have its own controller? Thanks,
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您所描述的实际上是 Zend Framework MVC 实现的标准最佳实践。这就是 Zend Framework “希望”您这样做的方式!为什么你担心这可能是不好的做法?
对于你的第二种提问方式...
不,但不要从页面的方向开始思考,而是从功能单元的角度思考。例如,如果您的页面需要用户管理,您很可能会有一个
userController
。该控制器需要实现哪些功能?
因此,这些功能中的每一个都成为 userController 中的一个操作(function = method = action)。
这样,您也将自动获得易于阅读的 URL。最后,每个操作都有一个 .phtml 视图脚本,其中驻留该操作所需的标记。
What you are describing is actually the standard best practice that Zend Framework MVC implements. That's how Zend Framework 'wants' you to do it! Why are you afraid it could be bad practice?
To your second way of asking...
No, but don't start thinking from the direction of pages, think in terms of functional units. For example, if your page needs user management, you will most likely have a
userController
.What are the functions this controller needs to fulfill?
So each of these functions becomes an action in your userController (function = method = action).
This way, you will automatically have easy to read URLs as well. And finally, every action has a .phtml view script, where the necessary markup for that action resides.
这根本不是坏习惯。考虑 PHP 应用程序常见的不同场景。为用户提供的 CRUD(创建、读取、更新、删除)。
所有操作都应在用户的同一控制器上。
我通常使用:
如果合适的话,添加和编辑使用相同的视图是有意义的,但是添加/编辑不可能与索引共享相同的视图。
That's not bad practice at all. Consider a different scenario common to PHP applications. A CRUD (Create, Read, Update, Delete) for Users.
All the actions should be on the same controller for Users.
I generally use:
It makes sense for add and edit to use the same view if appropriate, but there is no chance that add/edit could share the same view as index.