ColdMVC: The "MVC" Part

ColdMVC follows the Model-View-Controller (MVC) design pattern. In this type of application, incoming requests are handled by a controller, which retrieves data from the model, and passes it to the appropriate view for rendering.

The model layer contains your application’s business logic, typically inside persistent entities or service objects. Models in a ColdMVC application serve two purposes: to represent individual records in your database through properties as well as to provide database access through an abstraction layer on top of Hibernate ORM.

Models in ColdMVC contain several methods that help you easily query your database. Most of the methods are based on domain class methods found in Grails. Here’s a quick list of the what’s currently supported:

• add()
• count()
• countWhere()
• exists()
• findAll()
• findAllWhere()
• findWhere()
• get()
• has()
• list()
• new()

In addition to the methods mentioned above, ColdMVC also supports dynamic methods that are evaluated at runtime, which is made possible by leveraging ColdFuion’s support of onMissingMethod. For example, assuming you had a User model with properties for user name and password, the following code is completely valid without having to actually define the method on the User model:

params.user = _User.findByUserNameAndPassword(params.userName, params.password);

The view layer is the presentation layer of your application, in charge of displaying data from the model and providing the user with forms to input new data. Views are located inside your application’s /app/views/ folder and are chosen based on the incoming request. For example, a request to “/product/list” would display the view located at /app/views/product/list.cfm.

The controller layer is responsible for accepting a request, interacting with the model, and rendering the appropriate view. Controllers in a ColdMVC application are found inside the /app/controllers/ folder. The name of a controller should be the corresponding model name followed by “Controller”. For example, if your application has products, you would have a ProductController. As long as you follow this naming convention, ColdSpring will automatically find your controllers and autowire them as singleton objects.

By default, the corresponding model will be automatically autowired into the controller and be available as _{Model}. For example, the ProductController will have access to products through a _Product variable. Any other models can be autowired into a controllers using properties. If you wanted your ProductController to access categories, you can autowire a Category model into your controller by adding a _Category property.