I have seen approaches of AJAX requests to Controllers or Services (.asmx, .svc) that act as proxies to make calls out to Web Services on other domains.
Using a Service seems like the clean开发者_JS百科est and most logical route but are there any arguments for using calls to a Controller? I know some people would use .aspx pages and change the response to JSON but there was overhead with having the full page life cycle execute and just seems all around messy. I am ramping up on MVC at the moment and I'm wondering if Controllers would have the same overhead - I'd think some but very little with out MVC is architected.
Thoughts?
Per Dave's comment below add HttpHandler to the candidate list.
If you are using ASP.NET MVC and you want to create proxy service for your web application (it is not supposed to be consumed by any other application) then the most suitable is controller. It will make your architecture consistent.
HttpHandler is a good idea but I would still prefer controller because MVC will nicely handle routing to actions for you and you will still have easily testable code.
ASMX are mostly obsolete and WCF will be probably too much complicated and not needed for this.
For pure relay purposes, I like an ASHX HttpHandler on the server-side. It's just about the simplest thing to set up and has the least possible overhead.
精彩评论