Coldfusion, what is the advantage of the front controller over the page controller?

Question

I'm from a non-computer background, and I'm struggling to think about the approaches and structures of MVC in general. I "get" code reuse and separation of logic from the display, and I "get" encapsulation and decoupling, but I don’t understand this.

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

Most of the frameworks I looked at seem to prefer the front controller, so my simplified version of the MVC design of the top controller will be a subfolder for cfcs, controllers and views, and the 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 this give me over the design of the page controller? If these are not just the sites that I write, it always seems to me that the controller logic is presentation-specific, it does not look like one controller can correspond to several views, or several controllers can display one view, so what will the point be divided them?

The light has not yet appeared for me, no signs?

Answer 1

By the "top" controller, I think you mean the "front" controller , one entry point for requests to the application. As @bpanulla wrote, most ColdFusion frameworks use this design pattern. This becomes especially interesting with rewriting URLs , where it becomes easy to have a search engine secure URLs , intercepting the URL (e.g. domain.ext/i/am/friendly.ext ) and redirecting it to some standard file, such as index.cfm , making the required URL a parameter (often as a request header). It also makes website redesigning when URLs change easier because it is well suited for aliases or redirects.

Regarding controllers, they are usually closely associated with a specific URL or URL pattern. This may be more loosely related to controllers, but in practice I find that multiple refactoring occurs. What should be at the heart of the controller is one or more service level calls that negotiates with the database, executes a business process, creates objects with a state, etc. Then the controller receives the outputs of the service level and places them in any mechanism (for example, an event object) used to transmit data in the form of (representation).

This is the level of service that should be reused, not the controllers. Controllers are simply an extension of any infrastructure in which the application runs. The idea is that you should be able to switch frameworks with very little impact on the types and level of service. The piece to be touched is the controllers.

Thus, this service object at the service level should be able to serve multiple controllers. For example, consider displaying registered user information as a widget on a site. Different servers may have different pages, but each of them will call the same service object to register in user data, which supposedly can be provided to the same view that the widget displays.

Update: Front Controller Benefits

• Security : centralized authentication and authorization.
• i18n and l10n : enter the correct language pack in a query around the world
• Process Orchestration : think of a multi-step procedure for checking the shopping cart, where you do not need buttons back and forth - by laying everything through the front controller, you can ensure that the step is executed (i.e. the state)
• Logging and tracking : it’s easy to add Google Analytics or other tracking of requests to the site, making the addition in only one place.
• Error Handling : Centralized Behavior

Now many of these elements can also be executed using <cferror> and Appplication.cfc , but it’s easier for me to have one central point.

useful links

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

Answer 2

In fact, you have implemented the essence of Fusebox (http://www.fusebox.org/) with what you wrote. There is nothing wrong with this, and most of the ColdFusion community has used something similar to this for many years - Fusebox was the most used CF framework (in my experience), until only a few years ago, when ModelGlue, Mach-II and other second generations CF frameworks.

One thing that I can pay attention to is that your approach to controllers (like .cfm files) does not actually provide encapsulation in the typical OOD method, and the specific arguments go to the call to the object method. Unless you are extremely dull, over time your .cfm controllers can complete the accumulated large number of undocumented parameters that change behavior to solve a particular problem.

With various frameworks, you also get nice features like Application, Session and Request for special code (onApplicationStart, onRequestEnd, etc.). But you can always get them through a simple Application.cfc.