Hi Brian,
It shouldn't really be the case that your controller methods ends up being
massive, if it is, then I'd hazard a guess that you're doing too much in
your controller when really that code should be moved into a service layer.
Things like business rules, queries, orm functions or transactions in a
controller method are a red flag, and code needs re-factoring
If I have complicated processes to handle then I place them in a service,
the service will then take whatever inputs are needed and process them. If
an error occurs I have my service throw a custom exception that can be
caught in the controller.
function myControllerMethod(event) {
var args = event.copyToScope({}, "foo,bar,baz");
try {
var result = getMyService().doSomething(argumentCollection=args);
}
catch(InvalidFoo fooexc) {
// foo was invalid, maybe redirect back to a form or something
}
catch(any e) {
// something unexpected happened
}
// we're done, no errors, cool beans!
}
My controller has no idea what goes on inside the doSomething() method,
only that it requires certain arguments, can throw a number of errors and
returns a result. What the service does internally (maybe aggregating a
dozen other service methods) is of no concern of the controller.
As a rules of thumb, I only allow controllers to talk to services, and
services to talk to gateways.
Hope that helps,
Chris
On 18 February 2013 22:29, Brian G <[email protected]> wrote:
>
> Dan - thanks for the suggestion, will look into this. Would you use a
> queue to keep them separate or how, at the controller event level do you
> prevent it from running two work tokens simultaneously?
>
>
> On Tuesday, February 12, 2013 12:44:49 PM UTC-8, Dan Wilson -
> [email protected] wrote:
>
>> Would it be possible to use a Work-Token as your unit of work? Then you
>> would be able to operate on the Work-Token, rather than the information
>> from the session/user.
>>
>> The Work-Token can be a UUID or whatever you like. Generate this when the
>> top-line entry point in the MG application is called. Process all your
>> units of work against the Work-Token (even if you have to translate that
>> into the user information for the database) and that way, even if the
>> submission happens twice, the long running requests will be shielded from
>> crossing streams.
>>
>> DW
>>
>> Brian G
>> Tuesday, February 12, 2013 3:22 PM
>>
>> I have some fairly lengthy processes that run one after another when
>> saving e-commerce transactions to the system. For maintainability, these
>> are spread across a few different events (which lets me error out and abort
>> in certain cases cleanly). However, I do want to protect against a
>> double-click or multiple submission from causing wonkiness (imagine the end
>> of the routine empties out an array as things are processed successfully
>> which leads to another running thread to wind up with an inconsistent array
>> length).
>>
>> Normally I'd wrap it in a cflock but this spans multiple MG events. Any
>> suggestions on another way to attack this? I don't really want to have one
>> monster controller event as I like the readability and the ability to reuse
>> individual broadcasts in other events.
>>
>> I suppose I could do some kind of a session flag and use that as a lock
>> but that would really just stop the extra requests rather than queue them.
>> Any other ideas?
>>
>>
>> Brian
>>
>> --
>> --
>> Model-Glue Sites:
>> Home Page: http://www.model-glue.com
>> Documentation: http://docs.model-glue.com
>> Bug Tracker: http://bugs.model-glue.com
>> Blog: http://www.model-glue.com/blog
>>
>> 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
>> model-glue+...@**googlegroups.com
>>
>> For more options, visit this group at
>> http://groups.google.com/**group/model-glue?hl=en<http://groups.google.com/group/model-glue?hl=en>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "model-glue" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to model-glue+...@**googlegroups.com.
>>
>> For more options, visit
>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>
>> --
> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "model-glue" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
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
---
You received this message because you are subscribed to the Google Groups
"model-glue" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
