model view controller - Handling Ajax in MVC architecture - Stack Overflow

admin管理员组

文章数量:1122846

My question is in regards to the ideal/preferred approach to handling Ajax requests in an MVC structure.

In particular, about whether it's considered a good practice to create a separate controller that can serve Ajax requests as opposed to keeping all that logic inside of your normal controllers that also serve HTML views, etc. I've read arguments that suggest you should avoid creating another Ajax controller and instead have Ajax calls request actual resources (i.e. Comments::create(), etc).

The issue I have with this approach to keeping both regular logic and Ajax-related code inside a single controller method is that I'd prefer to not have to litter each one of my controller methods with code like the following:

if (isAjax()) {
    // Possibly also check HTTP method...
    ... handle Ajax request (return XML, JSON, etc) ...
} else {
    // Possibly also check HTTP method...
    ... handle normal request (render HTML view, etc) ...
}

not to mention if some methods only allow certain HTTP methods to access them, it seems the logic in each method could get rather complicated fast.

People say that having a separate Ajax controller would create duplicate code and be hard to maintain. I'm not sure I fully understand why that would be since if I keep most of my business logic inside the models, then what's the difference of a regular controller vs an Ajax controller instantiating the same model and calling its methods? There would still be only one copy of the business logic in the model it's just that it's being called from another controller devoted singly to handling Ajax requests.

I've also seen arguments that say the controller shouldn't care where the request is coming from, etc and I agree with those thoughts, but...

I tend to prefer the "separate Ajax controller" line of thinking because I'm a strong advocate of clean code and I'd rather not add tons of extra conditionals to my normal controller methods to determine whether the request is XHR, etc. The assumption is that if the request is hitting the Ajax controller, it's XHR and I can simply call the same model code from that controller that anywhere else would but now I don't have conditionals everywhere throughout my codebase.

That's the gist of what I'm getting at but I'm wondering whether there are other options or if I'm overlooking some sort of design flaw by creating another controller to serve Ajax calls. At the end of the day, I agree with having requests call the resources they're associated with rather than some generic Ajax controller but couldn't we just further segregate the Ajax controller(s)/method(s) into groups that serve "resources" in a similar way?

I'm not so worried about the number of controllers, etc as much as I am about the code being clean and easy to read/understand. I prefer having code that isn't too deeply nested in conditionals all over the place.

Thus, Ajax controller methods could be very simple wrappers around the model methods such as:

public function do_action() {
    // Return JSON-encoded result of SomeModel->do_action();
}

One downside I can think of with the separate Ajax controller approach is the need to potentially define more routes.

One upside I can think of the separate Ajax controller approach is that it seems to be a motivating force for keeping more of your business logic in models so that you dont end up with duplicate code.

What are your thoughts? Do you know of other alternatives?

本文标签： model view controllerHandling Ajax in MVC architectureStack Overflow