在 MVC 中，如何根据视图、模型和路由构建#Controller？
我有一个关于 MVC 应用程序结构的问题。假设我们要实现一个基于Web的应用程序，由多个模块组成，例如购物车、商店浏览器（最终用户）、商店管理员（管理员）等。
当然可以创建一个控制器并使用路由将请求提交到特定控制器的操作方法。然而，这会使代码变得非常混乱，并阻碍垂直构建应用程序的实践，即识别和区分涉及哪些视图、模型和控制器来满足特定需求（菲尔·哈克）。
另一种方法是为每个应用部分使用一个控制器，例如一个控制器用于最终用户操作，另一个控制器用于商店管理员，另一个控制器用于运输部门的查询，等等。这种方法的缺点是控制器太多，会弄乱您的代码，过于专用于特定任务，因此难以重用。
根据这两种极端情况，组织控制器和路由策略的最佳方式是什么？您使用结构化方法还是取决于您正在开发的应用程序类型？
谢谢
弗朗西斯科
I have a question concerning the structure of an MVC application. Suppose we have to realize a web-based application composed by several modules, such as shopping cart, store browser(end-user), store manager(admin) and so on.
It is of course possible to create one controller and use the routing to submit the requests to a specific controller's action method. However this would make the code quite messy and hinder the practice to vertically structure the application, namely to identify and distinguish which views, models and controllers are involved to fulfill a specific requirement (an example is given by Phil Haack).
Another approach is to use one controller for each application section, for instance one controller made available for end-user operations, another for the store administrator, another one for queries made by the shipping department and so on. The drawback to this approach is to have too many controllers that mess up your code, too dedicated for specific tasks and so difficult to reuse.
According to this two extreme situation, what is the best way to organize your controllers and routing policies? Do you use a structured approach or it depends on the type of application you are developing?
Thanks
Francesco
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您忽略了第三种替代方案，这是最常见的一种。一般来说，您应该每个资源有一个控制器。 资源是公开公开的模型。在您的特定店面应用程序中，资源可能是
Products、Orders、Customers等。这通常是正确的抽象级别，因为控制器通常不需要了解除了他们接触的资源之外的模型。应该对涉及多个资源的控制器持怀疑态度，因为它违反了单一责任原则。
You're overlooking a third alternative, which is the most common one. In general you should have one controller per resource. A resource is a model that is publicly exposed. In your specific storefront application, the resources would be things like
Products,Orders,Customers, etc.This is typically the proper level of abstraction, because controllers usually don't need to know about models other than the resources they touch. A controller that touches more than one resource should be viewed with some skepticism, since it's violating the single-responsibility principle.
您应该尝试尽可能遵循 REST
基本上 - 这意味着每个“集合的控制器” '（您的实体）。
如果您的控制器是 RESTful 的，其他部分（路由、视图）将相应地适合自己。
You should try to follow REST as much as possible
Basically - that means controller for each 'collection' (Your entity).
If Your controllers will be RESTful, other parts (routing, views) will fit themselves accordingly.