我有一个建立为ASP.NET 3.5 Web App的已建立的Web应用程序。我们最近修改了它以将MVC混合到应用程序中以获得一些新功能。
现在它已经存在，我们希望尽可能利用MVC开始将应用程序从笨重的webforms“转换”为更易于维护和可测试的MVC应用程序。
添加一些新功能时出现的问题是控制器应该对某个操作负责。
让我更详细一点。
该方案涉及我们的应用程序中至少三个主要概念区域。应用程序需要能够在SEARCH屏幕上为默认MAP视图设置其PREFERENCE。首选项，地图和搜索都是我们系统中的主要概念。此外，此偏好设置（基本上，地图应该从哪里开始）可用于在多个搜索页面中设置初始地图（它基本上是搜索偏好）。
应用程序中现有的MVC控制器是MAPCONTROLLER，有3个操作负责生成要放在地图上的HTML或JSON数据。
我们现在需要做的是添加一个MVC路由（控制器+动作），以允许客户端视图保存一些信息作为他们的偏好。基本上，只要他们在搜索页面上查看地图，他们就可以点击一个“记住这个作为我的默认地图视图”的按钮，从那时起，他们的地图将始终以该视图开始。
我的问题是（我道歉，但我想非常清楚，我看到太多问题没有背景帮助）。我的控制器代表什么？我显然有三个主要的系统领域。使用SaveDefaultMapView操作（不需要查看）创建新的SEARCH或PREFERENCES控制器，或者在xisting MAP控制器上搭载是否合适？即使这个新功能更多地是关于搜索和偏好而不是实际的地图生成？ MVC控制器应该主要与屏幕（搜索页面/搜索子系统），被操纵的域/数据（首选项），还是在采取行动时受到详细检查的非常具体的视觉元素（地图）对齐？
所有示例和bootcamp项目都很好，但它们太干净和简化，无法应用于庞大的遗留应用程序。如何围绕将多个域关注点合并到一个网页中的系统设计其MVC组件？
全部谢谢！
答案 0 :(得分：0)
控制器的组织方式没有硬性规定。您可以按照对您最具逻辑意义的方式组织它们。当你看到路由如何工作时，这将需要一些实验，你会找到最干净，最优雅的设计。
ASP.NET MVC在这方面非常不可知。它并不关心您如何设计控制器/路径子结构，并且它足够灵活，可以处理大多数设计。
您的应用程序设计应该在模型方面很重要。你的控制器应该相对较小;如果您发现在控制器中填充了大量逻辑，则应将该逻辑重构为模型，或添加服务层以包含逻辑。您的控制器层最好被认为是“补丁面板”;它是您通过路径将传入的URL连接到模型/服务层和视图模型/视图的地方。
您一定要查看Project Areas，因为这可能是包含三个不同系统区域的合适机制。
答案 1 :(得分：0)
谢谢，罗伯特。 我想我可以改写一下......其他人发现哪些指导方针对于保持控制器职责的组织和逻辑有用？ 虽然我上面的例子只涉及我们的3个区域，但我希望最终用MVC替换大部分/全部应用程序。 此外，我提到的3个区域中的每个区域都与多个其他区域有关系（例如，地图可用于绘制多个基于位置的实体，偏好可应用于系统的任何区域，并且像地图一样，能够搜索对于几种业务实体（一次一个，而不是一起）。 所以线条模糊。我很想听听别人如何为控制器组织找到可行的指导方针。 哦，至少，我们坚持瘦瘦的控制器/脂肪模型范例！