我的 ASP.NET MVC 控制器应该代表什么 - “真实世界”应用程序

Question

我有一个建立为 ASP.NET 3.5 Web 应用程序的 Web 应用程序。我们最近对其进行了修改，将 MVC 混合到应用程序中以获得一些新功能。

现在有了它，我们希望尽可能利用 MVC 开始将应用从笨重的网络表单“转换”为更易于维护和测试的 MVC 应用。

在添加一些新功能时刚刚出现的问题是哪个控制器应该负责某个操作。

让我更详细一点。

该场景涉及我们应用程序中的至少三个主要概念领域。应用程序需要能够在搜索屏幕上时为默认的 MAP 视图设置 PREFERENCE。偏好、地图和搜索都是我们系统中的主要概念。此外，此首选项设置（基本上，地图应该从哪里开始）可用于在多个搜索页面中设置初始地图（基本上是搜索首选项）。

应用中现有的 MVC 控制器是一个 MAPCONTROLLER，有 3 个操作负责生成 HTML 或 JSON 数据以放置在地图上。

我们现在需要做的是添加一个 MVC 路由（控制器 + 动作），以允许客户端视图保存一些信息作为他们的偏好。基本上，每当他们在搜索页面上查看地图时，他们都可以单击“记住这是我的默认地图视图”的按钮，从那时起，他们的地图将始终以该视图开始。

我的问题是（我很抱歉，但我想非常清楚，我看到太多的问题没有上下文可以帮助）。我的控制器应该代表什么？我显然涉及 3 个主要的系统领域。使用 SaveDefaultMapView 操作（不需要视图）创建新的 SEARCH 或 PREFERENCES 控制器是否合适，或者在现有 MAP 控制器上搭载，即使这个新功能更多地是关于搜索和偏好而不是实际地图生成？ MVC 控制器是否应该主要与屏幕（搜索页面/搜索子系统）、被操作的域/数据（首选项）或在采取行动时正在审查的非常具体的视觉元素（地图）对齐？

所有示例和训练营项目都很好，但它们过于简洁和简化，无法应用于大型遗留应用程序。如何围绕一个将许多领域关注点合并到一个网页中的系统来设计他们的 MVC 组件？

谢谢大家！

Answer 1

对于控制器的组织方式没有硬性规定。您以对您最合乎逻辑的方式组织它们。这需要进行一些试验，因为您会看到布线的效果，并且您会找到最简洁、最优雅的设计。

ASP.NET MVC 在这方面非常出色。它不关心你如何设计你的控制器/路由子结构，它足够灵活，可以处理大多数任何设计。

您的应用程序设计在模型方面应该很重。您的控制器应该相对较小；如果您发现在控制器中填充了大量逻辑，则应该将该逻辑重构到模型中，或者添加一个服务层来包含该逻辑。最好将您的控制器层视为“接线板”；它是您通过路由将传入的 Url 连接到模型/服务层和视图模型/视图的地方。

您绝对应该查看Project Areas，因为这可能是包含您的三个不同系统区域的合适机制。

Answer 2

谢谢，罗伯特。 我想我可以改写一下......其他人发现哪些指导方针有助于保持他们的控制器职责有条理和合乎逻辑？ 虽然我上面的示例仅涉及我们的 3 个领域，但我希望最终用 MVC 替换大部分/所有应用程序。 此外，我提到的 3 个区域中的每一个都与多个其他区域有关系。（例如，地图可用于绘制多个基于位置的实体，偏好可应用于系统的任何区域，并且像地图一样能够搜索适用于多种业务实体（一次一个，而不是全部）。 所以线条很模糊。我有兴趣了解其他人如何为控制器组织找到可行的指导方针。 哦，至少，我们坚持使用瘦控制器/胖模型范式！