我来自非计算背景，而且我很难全面了解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>
..但是，通过页面控制器设计给我带来了什么真正的优势？除非它只是我写的那种网站，我似乎总是发现控制器逻辑特定于一个视图，它不像一个控制器可以适合多个视图或者几个控制器可以输出到一个视图，那么什么是重点分开他们？
光还没有发现，还有什么指针？
答案 0 :(得分：4)
通过“顶级”控制器，我认为你的意思是"front" controller，是申请进入申请的单一入口点。正如@bpanulla所写，大多数ColdFusion框架都使用这种设计模式。这对于URL rewriting变得特别有意义，通过拦截某个网址（例如domain.ext/i/am/friendly.ext）并将其路由到某个标准文件（例如index.cfm），可以轻松获得search engine safe URLs使请求的URL成为参数（通常作为请求标头）。这也使网站重新设计的URL更容易变更，因为它很适合于别名或重定向。
就控制器而言，它们通常与特定的URL或URL模式紧密耦合。它可能与控制器更松散地耦合，但实际上我发现在多次重构之后这是一个紧急属性。控制器的基础应该是对service layer的一次或多次调用，它与数据库通信，执行业务流程，创建有状态实体等等......然后控制器接收服务层的输出并将它们置于任何机制中（例如，event对象）用于将数据传递给视图。
服务层的意思是可重用，而不是控制器。控制器只是应用程序在其中工作的任何框架的扩展。我们的想法是，您应该能够切换框架，而对视图和服务层的影响非常小。需要触摸的部分是控制器。
因此，服务层中的给定服务对象应该能够为多个控制器提供服务。例如，考虑将登录用户的信息显示为站点上的窗口小部件。可能存在由不同控制器服务的不同页面，但是每个控制器都会调用相同的服务对象来登录用户数据，这些用户数据可能被提供给呈现窗口小部件的相同视图。
现在很多这些项目也可以使用<cferror>和Appplication.cfc完成，但我发现更容易拥有一个集中点。
有用的链接
答案 1 :(得分：2)
你实际上用你写的内容实现了Fusebox（http://www.fusebox.org/）的关键。这没有什么不妥，而且大多数ColdFusion社区多年来都使用类似的东西 - Fusebox是最常用的CF框架（根据我的经验），直到几年前，ModelGlue，Mach-II和其他第二个一代CF框架出现了。
我可以指出的一点是，您对控制器的方法（如.cfm文件）实际上并没有以典型的OOD方式强制执行封装，特定参数将转到对象方法调用。除非你非常愚蠢，否则随着时间的推移，你的.cfm控制器可能会累积大量未记录的参数，这些参数会改变行为以解决一个或另一个问题。
通过各种框架，您还可以获得很好的功能，如应用程序，会话和请求特定代码（onApplicationStart，onRequestEnd等）。但是你总是可以通过一个简单的Application.cfc来获取它们。