Is Model-Glue's model in Coldfusion the same as the model in other MVC frameworks?

If you follow the quickstart guide provided by the official Model-Glue docs, found here:

http://docs.model-glue.com/wiki/QuickStart/2%3AModellingourApplication#Quickstart2:ModelingourApplication

It will seem like the "model" is a class that performs an application operation. In this example, they created a Translator class that will translate a phr开发者_JS百科ase into Pig Latin. It's easy to infer from here that the program logic should also be "models", such as database operation classes and HTML helpers.

However, I recently received an answer for a question I asked here about MVC:

Using MVC, how do I design the view so that it does not require knowledge of the variables being set by the controller?

In one of the answers, it was mentioned that the "model" in MVC should be an object that the controller populates with data, which is then passed to the view, and the view uses it as a strongly-typed object to render the data. This means that, for the Model-Glue example provided above, there should've been a translator controller, a translator view, a PigLatinTranslator class, and a Translation model that looks like this:

component Translation
{
    var TranslatedPhrase = "";
}

This controller will use it like this:

component TranslatorController
{
    public function Translate(string phrase)
    {
        var translator = new PigLatinTranslator();
        var translation = new Translation();
        translation.TranslatedPhrase = translator.Translate(phrase);

        event.setValue("translation", translation);
    }
}

And the view will render it like this:

<p>Your translated phrase was: #event.getValue("translation").TranslatedPhrase#</p>

In this case, the PigLatinTranslator is merely a class that resides somewhere, and cannot be considered a model, controller, or a view.

My question is, is ColdFusion Model-Glue's model different than a MVC model? Or is the quickstart guide they provided a poor example of MVC, and the code I listed above the correct way of doing it? Or am I completely off course on all of this?

I think perhaps you're getting bogged down in the specifics of implementation.

My understanding of (general) MVC is as follows:

• some work is needing to be done
• the controller defines how that work is done, and how it is presented
• the controller [does something] that ultimately invokes model processing to take place
• the model processes handle all data processing: getting data from [somewhere], applying business logic, then putting the results [somewhere]
• the controller then [does something] that ultimately invokes view processing to take place, and avails the view processing system of the data from the model
• the view processes grab the data they're expecting and presents that data some how.

That's purposely very abstract.

I think the example in the MG docs implement this appropriately, although the example is pretty contrived. The controller calls the model which processes the data (an input is converted into an output), and then sets the result. The controller then calls the view which takes the data and displays it.

I disagree with the premise of this question "Using MVC, how do I design the view so that it does not require knowledge of the variables being set by the controller?" The view should not care where the data comes from, it should just know what data it needs, and grab it from [somewhere]. There does need to be a convention in the system somewhere that the model puts the data to be used somewhere, and the view gets the data it needs from somewhere (otherwise how would it possibly work?); the decoupling is that model just puts the data where it's been told, and the view just gets the data out from where it's been told. The controller (or the convention of the MVC system in use) dictates how that is implemented. I don't think MG is breaking any principles of MVC in the way it handles this.

As far as this statement goes "In this case, the PigLatinTranslator is merely a class that resides somewhere, and cannot be considered a model, controller, or a view." Well... yeah... all a model IS is some code. So PigLatinTranslator.cfc models the business logic here.

And this one: "In one of the answers, it was mentioned that the "model" in MVC should be an object that the controller populates with data, which is then passed to the view"... I don't think that is correct. The controller just wrangles which models and which views need to be called to fulfil the requirement, and possible interchanges data between them (although this could be done by convention, too). The controller doesn't do data processing; it decides which data processing needs to be done.

Lastly, I don't think the "strongly-typed" commentary is relevant or an apporpriate consideration in a CF environment because CF is not strongly typed. That is a platform-specific consideration, and nothing to do with MVC principles.

I think one of the common confusions around MVC is that there are multiple Views, multiple Controllers but only one Model. cfWheels has a "model" object for each persistent domain object which I think is very confusing - but of course cfWheels is drawn from Ruby on Rails which also uses "model" in that context.

In general, in MVC, "The Model" represents your business data and logic as a whole. The Model is made up of a number of domain objects (which are typically persistent) and a number of service objects (which exist to orchestrate operations across multiple domain objects). In real world applications, you typically have a data layer that manages persistence of domain objects - which may be partitioned in a number of ways.

It may also help to think of the input data that the view needs as it's "API" and it is the controller's job to satisfy that API by providing compatible data. Think of it more that the controller needs to know what type of data will satisfy the view rather than the other way around.