何时将 MVC 视图拆分为两个？
有一天，我与一位同事讨论了 MVC 的最佳实践，他问我如何最好地分离视图。他正在维护一个 MVC 解决方案，该解决方案具有一个通用输入表单，其中一个控制器具有两个操作（一个获取操作和一个后置操作）。两个操作都返回相同的视图，其中充满了内联逻辑，以及检查它是帖子还是获取的条件。
对于这种情况，最好的解决方案是什么？ 是否应该将视图分成两个单独的视图？我想这取决于其中有多少逻辑，但是什么时候太多呢？有没有办法量化何时可以激励重构为两个视图？
I discussed best practices in MVC the other day with a colleague and he asked me how to best separate views. He was maintaining an MVC solution which had a common input form with a controller with two actions, a get action, and a post action. Both actions were returning the same view, which was filled with inline logic, and conditionals checking whether it was a post or a get.
What is the best solution for this situation?
Should the view be split into two separate views? I guess it depends on how much logic is in there, but when is too much? Is there a way to quantify when you can motivate the refactoring into two views?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我肯定会将类似的东西分成两个单独的视图，然后对它们之间的共同部分使用部分视图。
在规划
视图时，没有继承和条件逻辑的组合几乎总是更干净、更清晰、更易于维护的方法。I would definitely separate something like that into two separate views and then use partial views for the parts that are in common between them.
Composition, without inheritance and without conditional logic, is nearly always the cleaner, clearer, more maintainable way to go when it comes to planning
Views.