我只是在学习ASP.NET MVC的基础知识,并且想知道在多个控制器之间分解网站逻辑的好处是什么,而不仅仅是拥有一个运行整个网站的Controller类,而不仅仅是更好地组织代码。 (在我看来,由于关注点分离,后者的好处不应该足以通过URL影响最终用户:网站的实施细节不应该反映在网站使用的网址中,不是吗?)
我一直在阅读的控制器上的一些示例显示了“Product”或“User”或“Post”等不同的控制器。这些明确对应于对象类,后面跟着可以采取的操作(现在看到url,我看到stackoverflow.com/questions/ask)。
将网站拆分为单独的控制器类(例如QuestionsController)与仅使用单个默认控制器并在其中处理这些操作是否有优势,例如stackoverflow.com/ask-question(除了它看起来稍微丑陋)。< / p>
我问,因为我对使我的网站RESTful不是特别感兴趣(我对它进行了一些调查,但认为它太有限)而是支持查询字符串参数来传递有关请求的信息。因此,将URL拆分为控制器和动作的概念对我来说没有意义,因为动作和类信息将在查询字符串中表示。
最后,我更喜欢更简单的网址,例如www.mysite.com/about和www.mysite.com/home/about(这甚至意味着什么?),再次让我想知道多重点是什么控制器确实是。
答案 0 :(得分:5)
您几乎可以使用ASP.Net MVC路由实现任何您想要的网址方案。您拥有哪些控制器以及您的操作位置与您的网址无关。只有路由定义了您的网址。因此,为了特定的网址方案,没有任何理由牺牲代码清晰度和组织。
此外,在我看到的大多数ASP.Net MVC应用程序中,控制器已经很笨重,将它们全部组合到一个控制器中会增加指数的混乱。
即使是小型网站也只有少数或两个控制器。重要网站有数十个,非常大的网站可能有数百个。您真的认为以任何方式完全可行将数十个控制器合并为一个控制器吗?
答案 1 :(得分:4)
ASP.NET MVC的美妙之处在于它使关注点的分离变得如此简单。与ASP.NET Webforms(其中每个页面基本上是View 和 Controller)不同,在ASP.NET MVC中,您可以将模型逻辑抽象为单独的关注点或“功能组”。有一个ProductsController来处理与Products有关的所有事情是有意义的,因为你可以将应用程序中的每组相关功能分离成可独立测试和维护的统一组。
拥有一个DoEverythingController从根本上打败了MVC背后的推理,因为它将所有模型逻辑拼凑成一个巨大的意大利面条代码碗,而不是保持整洁有序。此外,让一个控制器执行所有操作并不是特别面向对象,并且类似于一种更加程序化的开发方法,就像许多(较旧的)PHP网站一样,它们具有一些中心“functions.php”或类似的所有 。这是混乱和混乱。
关于最后一点,MVC中的路由引擎允许您根据需要构建到给定控制器操作的路由。只要您相应地定义路由,ControllerX的About()操作和ControllerY的Contact()操作都可以具有/ about和/ contact等根URL。
修改(评论时间过长)
一般来说,就代码和逻辑而言,控制器类将非常薄。精心设计的控制器通常会处理更复杂的操作,例如从数据存储中检索数据到某种服务,以便故障的表面区域保持很小。尽管大多数控制器都“瘦”,但您的站点越大,运行所需的操作就越多,通用控制器就会变得越来越笨重。即使在非MVC场景中,巨大的代码文件仍然难以维护和更新(例如,上面的“functions.php”)。
如果您使用MVC开发的站点很小并且仅限于几个或多或少的静态页面,那么对所有这些站点使用单个控制器可能是一种合理的方法,但如果您构建可扩展的应用程序会随着时间的推移而变化,放弃使用多个控制器将是真正的失败者。
答案 2 :(得分:3)
是将所有文件放在同一目录中,还是将文件分隔在不同的文件夹中。 在许多情况下,将应用程序组织在单独的控制器中会有所帮助:
1)记忆表现
与许多请求共享控制器的Java Servlet不同,在asp net mvc中为每个请求创建控制器。 每次用户发出请求时,应用程序都需要创建控制器。 想想在内存中创建一个100k的胖控制器的实例VS一个1k的光控制器实例的性能比较。
2)OO好处
控制器是类。每次创建新控制器时,都会扩展基本控制器。 在复杂的应用程序中,您可以创建自己的控制(可以不止一个)并扩展更多的适用性。
例如,您可以为“产品”创建一个控制器并从中进行扩展,为“蔬菜产品”创建一个控制器等等。
3)安全。
假设您的应用程序中有一个页面,它对您的数据库的给定项执行CRUD操作: - 显示 - 编辑 - 更新 - 删除
您希望仅为注册用户保留此页面。
如果将所有这些方法放在一个单独的控制器中,则可以在控制器上放置注释[Authorize],默认情况下,控制器内的所有方法都将受到保护。 如果将所有应用程序放在一个胖控制器中,则必须小心地在每个方法上放置[Authorize](如果您原谅将注释放在delete方法上会发生什么?)
[Authorize]
public class ProductController
public ActionResult Index(String id) {
...
}
public ActionResult Update(String id) {
...
}
public ActionResult Delete(String id) {
...
}
4)安全再次。
假设您编写了经典CRUD(创建读取更新删除)。 现在你要删除整个CRUD。
如果您将代码保存在不同的控制器中,则只需删除与CRUD相对应的控制器。 如果将所有内容放在一个胖控制器中,则必须在整个代码中搜索与CRUD相似的方法。 再说一遍:如果您忘记删除Delete方法,那会是什么?
5)实用性
如果你把所有这些放在一起,你会有这样的方法:
product_edit
product_delete
product_rate
product_create
category_edit
category_delete
category_create
如果您在单独的控制器中组织代码,您将拥有
product
edit
delte
create
rate
category
edit
delete
create
这有很多原因:想要修改项目中的产品?只需重构并重命名itemController中的productController。
答案 3 :(得分:1)
chaiguy
我认为这个主题有可能说明(从答案中)使用控制器执行自己的“轻量级”任务的真正好处。立即想到的众多好处之一是,每个控制器都可以拥有相同的“相同”命名动作,而不管手头的任务(创建,编辑,删除,列表等)。
将这一点与数据访问的良好存储库模式和一些漂亮的T4模板相结合,您或多或少地获得了一个易于理解的“管道”工作,免费创建。
这使得mvc对我来说是一种纯粹的快乐 - 将相关操作谨慎地划分为统一的结构。正如前面提到的那样,可能会变得不那么笨拙而又很麻烦的是(不是双关语!!)熟悉和专注。
答案 4 :(得分:1)
我想如果你喜欢意大利面条,你只会有一个控制器。
复杂性,复杂性,复杂性,这就是问题所在。软件就是将问题分解为可管理的单元。
因此有多个控制器。