Chris,
Let me chime in here with the chorus of other voices:
The use of anything that extends
mogleglue.gesture.controller.Controller definitively binds your
application to the framework in question... however, since you're
only going to be extending the MG core controller class when you're
building your own controller in a ModelGlue app, it's a moot point...
using the built-in bean injection is just using a feature of the
framework when you're building an application that uses the framework.
Where you wouldn't want any reference to the framework is actually
one tier below the controller layer... your service layer. At least
in theory, your controller talks to services and services talk to
everything else.
Allow me to expound for a moment? :D
Let's look at a psuedo-codish method you might find in an MG controller:
<cffunction name="saveUser">
<cfargument name="event" />
<cfset var UserID = event.getValue("UserID",0)>
<cfset var userName = event.getValue("userName","")>
<cfset var emailAddress = event.getValue("emailAddress","")>
<cfset var password = event.getValue("password,"")>
<cfset var result = variables.instance.userService.saveUserProfile
(UserID,userName,emailAddress,password)>
<cfif result>
<cfset event.addResult("saveSucceeded")>
<cfelse>
<cfset event.addResult("saveFailed")>
</cfif>
</cffunction>
From this we can extract a few observations and parse them into a
couple rules of thumb that I use to keep my own mind pointed in the
right direction as I develop applications (not counting laziness,
client expectations, and/or anything else that may cause me to
randomly break my own thumbs):
1) Controller methods accept an event object as their sole argument.
It contains all the data from the form and URL scopes as well as
anything injected into it via onRequestStart events (often
application constants get stuck in the event object for convenience).
2) Service-layer functions take discrete arguments relevant to
whatever objects they're dealing with... so while in this example,
saveUserProfile(userId,username,emailAddress,password) is called with
discrete arguments extracted from the event object you could (were
you to be lazy and like to take chances with your apps) call
saveUserProfile(argumentCollection=event.getAllValues()) and have
done with it.
3) What goes on in the service layer is effectively hidden from the
controller and therefore the service methods can be used to very
simply service a Flex application, an application using a different
framework, or ad-hoc code. Using ColdSpring to manage your service-
layer allows you to use AOP and provide your service layer to Flex,
AIR and AJAX applications very easily and passing discrete arguments
into service methods can make your life a lot easier sometimes.
Variation on rule 2: passing Transfer (or Reactor, or your own Model)
objects from the service thru the controller into the view makes a
good many things a great deal easier. So having userService.getUser
(userID) return a User object that's then stuffed into the event
object is fine... so your controllers can then use things like
makeEventBean() and stuff which simplifies somethings and makes
others more difficult. I actually tend to prefer this variation in
practice, but prefer the notions of the other approach in theory.
So, the goal is to make your service layer be totally independent of
any other facility, but you can use built-in features of the
framework when you're creating application code in an app that's
making use of the framework.
Did that make sense? I can always try again: words are free! ;)
Laterz,
J
On Sep 22, 2008, at 11:15 AM, Chris H wrote:
>
> just a general question, because i've just gotten into ColdSpring and
> everything related:
> it's not a good thing to use the new automatic bean injection because
> this creates another tier to the framework (which according to Briak
> Kotek and others should be avoided). it's a nice feature to have for
> easy injection, but not ideal for a true OO design, right?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
For more about Model-Glue, check http://www.model-glue.com .
-~----------~----~----~----~------~----~------~--~---
