Coldfusion，什么是前控制器设计的优点在页控制器？ [英] Coldfusion, whats the advantage of front controller design over page controller?

问题描述

我来自非计算背景，我一直在努力让我的头围绕着MVC设计方法和框架。我获得代码重用，逻辑与显示分离，我获得封装和解耦，但我不明白。

I'm from a non-computing background and I'm struggling to getting my head around MVC design approaches and frameworks in general. I "get" code re-use, and separation of logic from display, and I "get" encapsulation and decoupling, but I don't get this.

此时，我只需将所有数据放在根目录中，为图像，cfcs和_includes提供单独的子文件夹，所有数据库都通过cfcs进行交互。我在页面的顶部做所有的处理，然后一个注释行然后显示/页面布局下面。

At the moment I simply put everything in root, a separate subfolders for images, cfcs, and _includes, all database interaction via cfcs. I do all my processing at the top of the page, then a comment line then display/page layout below that.

我看过的大多数框架似乎赞成一个前端控制器，所以我的顶层控制器MVC设计的简单版本将是cfcs，控制器和视图的子文件夹和index.cfm中的一个大开关语句

Most of the frameworks I have looked at seem to favour a front controller, so my simplistic version of a top controller MVC design would be a subfolder for cfcs, controllers, and views and a big switch statement in index.cfm

<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>

..但是什么真正的优势给了我一个页面控制器设计？除非它只是我写的那种网站，我总是似乎发现控制器逻辑是特定于一个视图，它不像一个控制器可以适合几个视图或几个控制器可以输出到一个视图，所以什么是要点分隔它们？

.. but what real advantage does that give me over a page controller design? Unless it's just the kind of sites I write, I always seem to find that the controller logic is specific to a view, its not like one controller could fit several views or several controllers could output to one view, so what would be the point of separating them?

灯还没有来，对我有用吗？

The light hasn't come on for me yet, any pointers?

推荐答案

由顶级控制器，我认为您的意思是前端控制器 ，对于到应用的请求的单个入口点。正如@bpanulla写道，大多数ColdFusion框架使用这种设计模式。使用网址重写变得特别有趣，其中很容易有搜索引擎安全网址，拦截网址（例如 domain.ext / i / am / friendly.ext ）并将其路由到某些标准文件，例如 index.cfm 一个参数（通常作为请求头）。这也使得网站重新设计，其中URL变得更容易，因为它很好地适用于别名或重定向。

By "top" controller, I think you mean "front" controller, a single point of entry for requests into an application. As @bpanulla wrote, most ColdFusion frameworks use this design pattern. This becomes particularly interesting with URL rewriting, where it becomes easy to have search engine safe URLs by intercepting the a URL (e.g. domain.ext/i/am/friendly.ext) and routing it to some standard file such as index.cfm while making the requested URL a parameter (often as a request header). This also makes site redesigns where URLs change easier because it lends itself well to aliasing or redirects.

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

As far as controllers are concerned, they are usually tightly coupled to a particular URL or URL pattern. It's possible be more loosely coupled with controllers, but in practice I find that's an emergent property after multiple refactorings. What should be underlying the controller is one or more calls to a service layer that talks to the database, executes business process, creates stateful entities, etc... Then the controller receives the service layer's outputs and places them into whatever mechanism (e.g. an event object) is used to pass data to the view(s).

这是服务层，意味着可重用的不是控制器。控制器只是应用程序工作的框架的扩展。这个想法是，你应该能够切换框架，对视图和服务层影响很小。需要触摸的部件是控制器。

It's the service layer that's meant to be reusuable not the controllers. The controllers are merely an extension of whatever framework an application works within. The idea being that you should be able to switch frameworks with very little impact to the views and service layer. The piece that needs to be touched are the controllers.

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

So a given service object in a service layer should be able to service multiple controllers. For example, consider showing a logged in users' information as a widget on a site. There might be different pages served by different controllers, but each would call the same service object to get logged in user data that presumably might be given to the same view that renders the widget.

• 安全 ：集中式身份验证和授权。


• i18n& ：针对购物车的多步骤结帐过程，其中包含以下内容： 你不想让后退和前进按钮工作 - 通过路由一切通过前控制器，你可以强制执行什么步骤（即状态）


• 记录和放大器。 ：集中行为：集中行为：只需一个地方即可轻松将Google Analytics（分析）或其他请求跟踪添加到网站


• 
  

• Security: centralized authentication and authorization.
• i18n & l10n: inject the right language pack into the request globally
• Process Orchestration: think multi step checkout process for a shopping cart where you don't want the back and forward buttons to work - by routing everything through the front controller you're able to enforce what step (i.e. the state)
• Logging & Tracking: easily add Google Analytics or other request tracking to a site by making the addition in just one place
• Error Handling: centralized behavior

现在，许多这些项目也可以使用< cferror> code> Appplication.cfc ，但我发现更容易有一个集中点。

Now many of these items can also be done using <cferror> and Appplication.cfc, but I find it easier to have one centralized point.

有用的链接

• http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html


• http://msdn.microsoft。 com / en-us / library / ff648617.aspx

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

这篇关于Coldfusion，什么是前控制器设计的优点在页控制器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！