Should I add WCF to my ASP.NET MVC site to feed data to mobile apps?

[I've never used WCF before. 开发者_如何学运维 I've been googling for a couple days and haven't found any info that makes my decision of whether or not to use it obvious to me.]

I've been developing a website using ASP.NET MVC, LINQ to SQL, and SQL Server.

Now I want to develop some mobile apps which will be fed data from the site's DB.

It has been suggested to me that I use WCF for this.

I know that if I have data facing the public internet, it can be scraped if someone really wants it, but I'd like to minimize the "scrapablility" of my data.

Since my mobile apps will probably just be sending/receiving data in JSON format, what benefits would I get from using WCF instead of just RESTful JSON-returning URI's in MVC?

And if I do implement WCF, should my MVC site be hitting those services for data also instead of using LINQ in my controllers?

---

I've got an ASP.NET MVC application hitting WCF. I originally developed it without WCF by having the controllers interact with a service layer that hits my repositories. A requirement came up during development that required me to physically separate the UI from the service layer.

Adding WCF was a pain in the rear. Things that worked without WCF no longer worked afterwards. For example, the state of my entities was lost upon transmission to/from the service layer making it very difficult to utilize certain features of my ORM (NHibernate). I could no longer retrieve an entity, map a viewmodel to the entity in my controller, and allow NHibernate to determine whether or not an update was necessary.

That said, the challenges associated with WCF were mostly incurred at the beginning. I don't need to revisit the configuration very often and I've gotten used to working with detached entities. I also have the benefit of physical separation and WCF is extremely flexible.

Would I use WCF if I needed web services but not the separation? I really don't know. I would probably try to make JSON action methods work because those are much easier (not to mention more fun). Keeping it simple is still a wonderful principle.

As for your MVC site hitting services? I think it's safe to say that your action methods should be very thin and there should be very little business logic or persistence concerns within your MVC project. Separation of Concerns makes it much easier to adapt and change your application.

---

I don't see any need for WCF. I'd consider an API area, or controller if the API is small, and deliver the data via JSON from a controller action. I'd refactor the app so that the API and your controllers use the same repositories. If you need to retrieve data via AJAX from your views, you can use the API, but I don't see any point in your controllers using them if they can take advantage of the repositories.