I had an interesting conversation with Sean Corfield last night, and while my understanding may be imperfect as of yet, here is what I came away with (I was asking for clarification as to some design patterns for object oriented coding)
The Model - the model should be pretty dumb, this would be the portion of the code that accesses your data. If you use Transfer or Reactor, they would be part of your model. I have several functions that call Transfer, for example:
These basic dumb getters are also part of my model.
Services - Services provide an interface to your model. For example, I may have a user service with many functions that are application specific. UpdateUser, registerUser, etc. These service functions will make calls to my model (which are the basic getters / setters) and basically route my data to the proper places. My service for user could also be responsible for creating a userBean to persist across the session.
Controller - the controller should handle incoming data from the user, and pass it to the appropriate controller. No application logic will reside in the controller, and in the case of Model Glue: Unity, the controller would be your ModelGlue.xml file. This simply recognizes where the user needs to be directed, and then passes incoming variables from the url and form into whichever service is required.
View - The view is simply display code. This is the only place that display code goes. Your services should make any necessary variables available to the view explicitly, and your view should never interact directly with the URL or Form scopes. If you need variables, your service layer should process those incoming variables (which it got from your controller) and place them into a scope that the view can access. When in model-glue, and inside a controller, you access those variables like this:
From within your view, you access your variables like this:
Its slow going for me, but I think I am getting a better grasp on the how, and I am getting the feel for the Why, but the why is a bit more slippery =) More to come as I grok it further.
The Model - the model should be pretty dumb, this would be the portion of the code that accesses your data. If you use Transfer or Reactor, they would be part of your model. I have several functions that call Transfer, for example:
<br /><cffunction name=<span class='cc_value'>"getItemsByAuctionID"</span> access=<span class='cc_value'>"public"</span> returntype=<span class='cc_value'>"void"</span> output=<span class='cc_value'>"false"</span>><br /> <cfargument name=<span class='cc_value'>"event"</span> type=<span class='cc_value'>"any"</span>><br /> <br /> <cfset var items = getTransferFacade().listByProperty(<span class='cc_value'>"item"</span>, <span class='cc_value'>"auctionID"</span>, arguments.event.getValue(<span class='cc_value'>"auctionID"</span>), <span class='cc_value'>"sortOrder"</span>) /><br /><br /> <cfset arguments.event.setValue(<span class='cc_value'>"items"</span>, items) /> <br /> <cfreturn /><br /></cffunction><br />These basic dumb getters are also part of my model.
Services - Services provide an interface to your model. For example, I may have a user service with many functions that are application specific. UpdateUser, registerUser, etc. These service functions will make calls to my model (which are the basic getters / setters) and basically route my data to the proper places. My service for user could also be responsible for creating a userBean to persist across the session.
Controller - the controller should handle incoming data from the user, and pass it to the appropriate controller. No application logic will reside in the controller, and in the case of Model Glue: Unity, the controller would be your ModelGlue.xml file. This simply recognizes where the user needs to be directed, and then passes incoming variables from the url and form into whichever service is required.
View - The view is simply display code. This is the only place that display code goes. Your services should make any necessary variables available to the view explicitly, and your view should never interact directly with the URL or Form scopes. If you need variables, your service layer should process those incoming variables (which it got from your controller) and place them into a scope that the view can access. When in model-glue, and inside a controller, you access those variables like this:
<br /><cfset myVar = arguments.event.getValue(<span class='cc_value'>"myURLorFormVar"</span>) /><br /><cfset arguments.event.setValue(<span class='cc_value'>"myVariableName"</span>, myVariableValue) /><br />From within your view, you access your variables like this:
<br /><cfset viewstate.setValue(<span class='cc_value'>"pageTitle"</span>, <span class='cc_value'>"This is my title"</span>) /><br /><cfset myLocalVar = viewState.getValue(<span class='cc_value'>"varNameFromEvent"</span>) /><br />Its slow going for me, but I think I am getting a better grasp on the how, and I am getting the feel for the Why, but the why is a bit more slippery =) More to come as I grok it further.
Recent Comments