我的 ASP.NET MVC 控制器应该代表什么 - “现实世界”应用
我有一个已建立的 Web 应用程序，构建为 ASP.NET 3.5 Web 应用程序。我们最近对其进行了修改，将 MVC 混合到应用程序中以实现一些新功能。
现在它已经存在了，我们希望尽可能利用 MVC 来开始将应用程序从笨重的 Web 表单“转变”为更易于维护和测试的 MVC 应用程序。
在添加一些新功能时刚刚出现的问题是哪个控制器应该负责某个操作。
让我说得更详细一些。
该场景至少涉及我们应用程序中的三个主要概念领域。当用户位于搜索屏幕时，应用程序需要能够为默认地图视图设置首选项。首选项、地图和搜索都是我们系统中的主要概念。此外，这一偏好设置（基本上，地图应该从哪里开始）可以用于在多个搜索页面中设置初始地图（它基本上是一种搜索偏好）。
应用程序中现有的 MVC 控制器是 MAPCONTROLLER，具有 3 个操作，负责生成要放在地图上的 HTML 或 JSON 数据。
我们现在需要做的是添加一个 MVC 路由（控制器 + 操作）以允许客户端视图保存一些信息作为他们的偏好。基本上，每当他们在搜索页面上查看地图时，他们都可以单击一个按钮，上面写着“记住这是我的默认地图视图”，从那时起，他们的地图将始终从该视图开始。
我的问题是（我很抱歉，但我想非常非常清楚，我看到太多没有上下文可以帮助的问题）。我的控制器应该代表什么？显然我涉及 3 个主要系统领域。使用 SaveDefaultMapView 操作（无需视图）创建新的 SEARCH 或 PREFERENCES 控制器是否合适，或者搭载在现有的 MAP 控制器上，即使这个新功能更多的是关于搜索和首选项而不是实际的地图生成？ MVC 控制器是否应该主要与屏幕（搜索页面/搜索子系统）、正在操作的域/数据（首选项）或在采取操作时接受审查的非常具体的视觉元素（地图）保持一致？
所有示例和训练营项目都很好，但它们过于干净和简化，无法应用于大型遗留应用程序。如何围绕将许多领域问题合并到单个网页中的系统来设计 MVC 组件？
谢谢大家！
I have an established web application built as an ASP.NET 3.5 Web App. We recently modified it to mix MVC into the app for some new functionality.
Now that it's in there, we want to leverage MVC wherever possible to begin to "transform" the app from clunky webforms to a more maintainable and testable MVC app.
The question that just came up in adding some new functionality is what controller should be responsible for a certain action.
Let me be more detailed.
The scenario involves at least three major conceptual areas in our app. The app needs to be able to set their PREFERENCE for a default MAP view while they are on a SEARCH screen. Preferences, Maps and Search are all major concepts in our system. Furthermore, this preference setting (basically, where should the map start out) may be used to set the initial map in more than one search page (it's basically a search preference).
The existing MVC controller in the app is a MAPCONTROLLER, with 3 actions that are responsible for generating HTML or JSON data to put on a map.
What we need to do now, is add an MVC route (controller + action) to allow the client view to save some information as their preference. Basically, whenever they are on the search page looking at a map, they can click a button that says "remember this as my default map view", and from then on, their map will always start with that view.
My question is (and I apologize, but I wanted to be very very clear, I see too many questions with no context to help). What should my controller represent? I obviously have 3 major system areas involved. Would it be proper to create a new SEARCH or PREFERENCES controller with a SaveDefaultMapView action (no view required), or piggyback on the xisting MAP controller, even though this new function is more about search and preferences than actual map generation? Should an MVC controller be aligned mostly with the screen (search page/search subsystem), the domain / data being manipulated (preferences), or the very specific visual element under scrutiny at the time the action is taken (the map)?
All of the examples and bootcamp projects are all well and good, but they are far too clean and simplified to apply to a huge legacy app. How does one design their MVC components around a system that incorporates many domain concerns into a single webpage?
Thanks all!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
谢谢，罗伯特。
我想我可以稍微改一下……其他人发现哪些指导方针对于保持控制器职责的组织性和逻辑性有用？
虽然我上面的示例只涉及我们的 3 个领域，但我希望最终用 MVC 替换大部分/全部应用程序。
此外，我提到的 3 个区域中的每一个都与多个其他区域有关系。（例如，地图可用于绘制多个基于位置的实体，首选项可应用于系统的任何区域，并且像地图一样能够搜索适用于多种业务实体（一次一个，而不是全部一起）。
所以界限是模糊的。我有兴趣了解其他人如何找到可行的控制者组织指南。
哦，至少，我们坚持瘦控制器/胖模型范式！
Thanks, Robert.
I guess I could rephrase a bit...what guidelines have others found to be useful for keeping their controller responsibilities organized and logical?
While my example above only touches 3 of our areas, I expect to eventually replace most/all of the application with MVC.
Furthermore, each of the 3 areas I mentioned has relationships to multiple other areas.(eg, maps can be used to plot several location-based entities, preferences can apply to any area of the system, and, like maps, is capable of searching for several kinds of business entities (one at a time, not all together).
So the lines are blurry. I'm interested in hearing how others have found workable guidelines for controller organization.
Oh, and at the very least, we are sticking to the skinny controller/fat model paradigm!
对于控制器的组织方式没有硬性规定。您可以按照对您来说最符合逻辑的方式来组织它们。这将需要一些实验，当您了解路由的工作原理时，您会发现最干净、最优雅的设计。
ASP.NET MVC 在这方面表现得非常出色。它不关心您如何设计控制器/路由子结构，并且它足够灵活，可以处理大多数设计。
您的应用程序设计应该以模型侧为主。你的控制器应该相对较小；如果您发现在控制器中填充了大量逻辑，则应该将该逻辑重构到模型中，或者添加一个服务层来包含该逻辑。您的控制器层最好被视为“配线架”；它是您通过路由将传入 URL 连接到模型/服务层和视图模型/视图的地方。
您绝对应该查看项目区域，因为这可能是包含三个不同系统区域的适当机制。
There are no hard and fast rules for how the controllers are organized. You organize them the way it makes most logical sense to you. This will require a bit of experimentation as you see how the routing works out, and you find the cleanest, most elegant design.
ASP.NET MVC is brilliantly agnostic in this respect. It doesn't care how you design your controller/route substructure, and it is flexible enough to handle most any design.
Your application design should be heavy on the Model side. Your controllers should be relatively small; if you find that you are stuffing a large amount of logic in the controllers, you should refactor that logic to the model, or add a service layer to contain the logic. Your controller layer is best thought of as a "patch panel"; it is the place where you connect your incoming Urls via routes to your model/service layer and your View Model/Views.
You should definitely check out Project Areas, as this might be an appropriate mechanism to contain your three different system areas.