"Real coupling" as in what? Not sure I follow. Decoupling (getting
things to talk without having to know who they're talking to) is one
of the primary goals of OO... so coupling isn't a goal unless you're
using the word in the sense of "hooking stuff up to other stuff"...
which is my guess.
And in that case, while I would suggest you not use a reserved
keyword ;), yeah... you plumb stuff together in CS by setting up your
singleton instances and wiring them together. And, indeed, using the
beans="" attribute in an MG controller is just a shortcut for doing
the exact same thing from within your app.
J
On Sep 23, 2008, at 2:57 AM, Chris H wrote:
>
> thanks all for your replies, especially Jared for his enormous one ;D
>
> so the "real" coupling should still happen at the Service & Gateway
> level (via Coldspring.xml). the new automatic injection into the
> Controller should just act as an easier way to "connect" it to the
> Service layer, correct?
>
> On Sep 22, 9:08 pm, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote:
>> 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 .
-~----------~----~----~----~------~----~------~--~---
