title: Pros and cons requesting JSON data from MVC Controller vs WCF service
body: <p>We designing a new ASP.NET MVC application and we have user controls that we would like to bind with JSON data</p>
  
  <p>1) we can implement a controller's action that returns JsonResult
  <a href="http://shashankshetty.wordpress.com/2009/03/04/using-jsonresult-with-jquery-in-aspnet-mvc/" rel="nofollow noreferrer">http://shashankshetty.wordpress.com/2009/03/04/using-jsonresult-with-jquery-in-aspnet-mvc/</a></p>
  
  <p>2) or we can implement a WCF service that also returns JSON
  <a href="https://stackoverflow.com/questions/2086666/wcf-how-do-i-return-clean-json">How do I return clean JSON from a WCF Service?</a></p>
  
  <p>Classes used for serialization are different JavaScriptSerializer vs DataContractJsonSerializer and I wonder do they share inside some common core Json serialization code or not, and how they compare in terms of performance and extensibility?</p>
  
  <p>I expect that if you use the same data model, 1st approach seems to be simplier to implement. 
  Are there any other considerations then implementation simplicity comparing <strong>JsonResult</strong> vs <strong>WCF [WebGet(ResponseFormat = WebMessageFormat.Json)]</strong> like performance, security, extensibility, scalability, testability etc.?</p>
  
  <p>p.s.
  I would like to clarify that this question is not about a decision of going with SOA approach or not, how to better separate concerns using architecture layers and so on. Our application already has WCF services to expose some data to 3rd party apps and to isolate the functionality that need to be isolated, so in terms of creating additional projects or hosting infrastructure and configuring WCF services - this all pretty much done already. Suppose the JSON data we want to obtain is not going to be reused somewhere else just for UI controls on a single web page. </p>