Ajax requests, through MVC Framework (e.g. ColdBox) or not?

[Henry]

http://stackoverflow.com/questions/1203902/ajax-requests-through-mvc-framework-e-g-coldbox-or-not

Looking forward to read your inputs... thanks!
Henry

[Cody Caughlan]

Hah, I actually responded to this on Stack Overflow before you posted it here.

[Brian Kotek]

It's overhead that serves no purpose. The only reason to call the controller is if you're generating CONTENT via AJAX, in which case you want the view to render UI elements. If you're just getting data, just call the service layer.

[jalpino]

One benefit of going through a framework is that your request will
follow the same access control restrictions as normal requests. Unless
you manage application security at a service layer, instead of
implicitly within the framework or at a controller level, then it
would make sense to go directly to the service layer.

One other benefit of going through the framework is that you retain
the ability to properly control the request in the event that the
users session has timed out and then the request is issued. With
ModelGlue, I typically append ".ajax" to my event handlers that are
called in that manner, in the event that a request is made and session
has timeout by common event handlers know to issue 403 status codes,
which my ajax engine knows how to handle (alert the user then redirect
to login).

Again, depending on where you manage your application security and how
you manage session (ie. alerting the user before their session times
out), it might make more sense to go through the framework, or go
directly against the service layer.

[Brian Kotek]

Which is exactly why you should be handling most of the security at the service layer. Sure, the controller or view might have some conditional logic or security checks for UI-related things like determining whether the main menu should show the "Admin" button or not. But the bulk of it should be handled in the service layer. Otherwise, as soon as you need to secure AMF or SOAP calls to the services, you're either duplicating the logic or you're going to have to move it all anyway.

[Alpino, Justin]

Good point, I guess it all depends on your requirements.

 

"The sender believes that this E-mail and any attachments were free of any harmful and malicious code or defects when sent. The sender is not liable for any loss or damage arising in any way from this message or its attachments. Confidentiality Note: This e-mail is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, is prohibited. If you have received this e-mail in error, please inform the sender, and destroy the original message and all copies."

[Henry Ho]

Yes, but if one uses Coldbox as their MVC framework of choice, the coldbox proxy ( http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbColdBoxProxyGuide ) would handle AMF and SOAP calls (if I'm not mistaken), so there are no duplicating the logic.

Henry

[Sean Corfield]

On Thu, Jul 30, 2009 at 10:24 AM, Henry Ho<henry...@gmail.com> wrote:
> Yes, but if one uses Coldbox as their MVC framework of choice, the coldbox
> proxy (
> http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbColdBoxProxyGuide )
> would handle AMF and SOAP calls (if I'm not mistaken), so there are no
> duplicating the logic.

Right, but IMO that's just a nasty hack added to ColdBox to support
people who are too stubborn to move their core business logic out of
their controllers and into their service layer :)

Model-Glue did this too for the same bad reason. Joe even had the
decency to say that Flex apps should not be built that way (they
should talk to a service layer directly).

So I'm with Brian on this.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood