Hello and thanks for looking!
Background
I am designing a greenfield application using .NET4 w/C# that will be packaged for/by Azure and run in the cloud.
One of the main functions of this application will be to listen for requests coming out of other cross-domain apps throughout the Internet, authenticate the request (method for doing that has not yet been determined), and then respond with data in the form of a JSON object.
This application will serve up data on a subscription/API basis and I will have no control or advanced knowledge of where future requests will originate.
In the past, I have created a MVC3 project in my solution as a "service" layer which simply listened on certain URLs (e.g. "mydomain.com/json") for data requests from the same domain. In response to the request, I would grab some data from SQL (entities actually), serialize it into JSON and then return it as return Content(foo,application/json) via the action result. This has worked GREAT.
The JSON will likely always be requested via ajax running on a client machine, so I am not that worried about threads being blocked on the server.
Please note, I know very little about WCF service projects and very little about Azure.
Question
Although I am very happy with the way my MVC JSON service pattern works in other applications, are there any major reasons I should NOT do this? Major reasons I should be using WCF instead?
I am tempted to subscribe to the "if it aint broke don’t fix it" philosophy, but I know that is not best practice.
I look forward to reviewing the advice of the brilliant minds on Stack Overflow regarding this matter!
Thanks,
Matt
With no arguments against using MVC methods, I am going to stick with them. I have found .NET MVC3 to be extremely flexible as a service brokerage layer, especially when using JsonFx as a JSON serializer allowing for low-cost data transport between tiers.