For example, lets imagine an application with a model containing a User package, Cart package, and a Products package. A view may ask to display a list of users and the products in their carts. To do this, the view can not ask the model to put all this together and pass it back. What if something changes about the data storage or location?
What you need is a go-between that can get this information from a source in a way that it doesn't matter if the underlying model changes. Or if the view changes, you won't have to change the model layer also. You need a controller to access the model and interact with the view.
Getting down to the meat of the matter, create your site with a model directory, view directory, and controller directory. It's up to you if you also use other parts such as UDF (user defined functions) directories, custom tag directories, asset directories, and other directories.
Then for instance you might have a User package (User diroctory) in the model directory that contains the user class (User.cfm), sometimes known as the DTO data transfer object. And also the UserService.cfm, UserGateway.cfm, and UserDAO.cfm. Sometimes you may also find use for a UserFacade.cfm or a UserTO.cfm.
All those files and functions in the model for User can almost be overpowering. Luckily you have a controller layer where you can put it all to good use in one file called the UserListener.cfm. If you instantiate the listener somewhere like the Application.cfc in a request scope, you can use this everywhere in your applications views. All you'll need to do is call the listener with the appropriate method, passing it whatever params required, and you'll have a powerful MVC application.
- Site root directory
- controllers
userListener.cfm
- model
- Users
User.cfm
UserDAO.cfm
UserGateway.cfm
UserService.cfm
- views
home.cfm
listUsers.cfm
Application.cfc
index.cfm
There are no comments for this entry.