Coldfusion,前端控制器设计优于页面控制器的优势是什么？

Question

我来自非计算背景,我很难全面了解MVC设计方法和框架.我"得到"代码重用,逻辑与显示分离,我"得到"封装和解耦,但我不明白.

目前,我只需将所有内容放在root中,为图像,cfcs和_includes创建单独的子文件夹,通过cfcs进行所有数据库交互.我在页面顶部进行所有处理,然后在注释行下面显示/页面布局.

我看过的大多数框架似乎都支持前端控制器,所以我的顶级控制器MVC设计的简单版本将是cfcs,控制器和视图的子文件夹以及index.cfm中的一个大的switch语句

<cfif not IsDefined("URL.event")>
    <cflocation url="index.cfm?event=home" addtoken="No">
</cfif>

<cfswitch expression="#url.event#">
    <cfcase value="home">
        <cfinclude template="controllers/home.cfm"/>
        <cfinclude template="views/home.cfm"/>
    </cfcase>
    <cfcase value="about">
        <cfinclude template="controllers/about.cfm"/>
        <cfinclude template="views/about.cfm"/>
    </cfcase>
</cfswitch>

..但是,通过页面控制器设计给我带来了什么真正的优势？除非它只是我编写的那种网站,否则我似乎总是发现控制器逻辑特定于视图,它不像一个控制器可以适合多个视图或者几个控制器可以输出到一个视图,那么什么是重点分开他们？

对我来说还没亮,任何指针？

Answer 1

我认为“顶部”控制器指的是“前端”控制器，它是应用程序请求的单一入口点。正如 @bpanulla 所写，大多数 ColdFusion 框架都使用这种设计模式。这对于URL 重写变得特别有趣，通过拦截 URL（例如）并将其路由到某些标准文件（例如将请求的 URL 作为参数（通常作为请求标头）），可以轻松获得搜索引擎安全的 URL 。这也使得 URL 更改的站点重新设计变得更容易，因为它非常适合别名或重定向。domain.ext/i/am/friendly.extindex.cfm

就控制器而言，它们通常与特定的 URL 或 URL 模式紧密耦合。它可能与控制器更松散地耦合，但在实践中我发现这是多次重构后的新属性。控制器底层应该是对服务层的一次或多次调用，该服务层与数据库通信、执行业务流程、创建有状态实体等……然后控制器接收服务层的输出并将它们放入任何机制（例如，eventobject）用于将数据传递到视图。

服务层才是可重用的，而不是控制器。控制器只是应用程序运行的任何框架的扩展。这个想法是，您应该能够切换框架，而对视图和服务层的影响很小。需要接触的部分是控制器。

因此，服务层中的给定服务对象应该能够为多个控制器提供服务。例如，考虑将登录用户的信息显示为站点上的小部件。不同的控制器可能提供不同的页面，但每个页面都会调用相同的服务对象来获取登录的用户数据，这些数据可能会被提供给呈现小部件的同一视图。

更新：前端控制器优势

• 安全性：集中认证和授权。
• i18n & l10n：将正确的语言包注入到全局请求中
• 流程编排：考虑购物车的多步骤结账流程，您不希望后退和前进按钮起作用 - 通过前端控制器路由所有内容，您可以强制执行哪个步骤（即状态）
• 日志记录和跟踪：只需在一处添加即可轻松将 Google Analytics 或其他请求跟踪添加到网站
• 错误处理：集中行为

现在，其中许多项目也可以使用<cferror>和来完成Appplication.cfc，但我发现拥有一个集中点更容易。

有用的链接

• http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
• http://msdn.microsoft.com/en-us/library/ff648617.aspx