Is there a reason to use WCF over asp.net MVC?

Question

If I am using knockout.js or angular.js for the presentation layer, also assume that the service layer needs to write data and read data from the database and it holds the business rules. Is there a reason why I should use WCF over asp.net MVC for the service layer? Calling an MVC controller that returns JSON data seems pretty simple, I can't think of a reason to use WCF.

Answer 1

If you are specifically targeting the web stack, ASP.NET MVC + WebApi would be the right combination on the server side.

The inherent support for JSON on both client and server makes a JSON-based API very popular. More and more public APIs from most of the providers are JSON-based or at least support JSON.

WCF may have its applicability in terms of server-to-server communications but for a web stack, I don't think it's a good fit. If you have a requirement to support multiple transport mediums, bind with protocols other than HTTP, support binary serialization for performance, complex security requirements, then WCF can help you.

Also for JSON based API, I suggest you use WebApi instead of using MVC and returning a JsonResult.

Answer 2

The point in WCF is to separate the means of getting the content from the logic itself. This would be helpful if you at a later point decided to re-use this logic for something that required a SOAP interface, or a binary binding.

If you use MVC, and you hard-code JSON as your output in your view layer, then you are tied to using that for your over the wire protocol. Plus, you will have to write a lot more of your object's JSON serialization yourself.

A lot of it depends on how you are structuring your services, and where you intend to put the flow control for your application. For example, say you are submitting a form to save some content. After the content is saved, do you intend to have the control over where to go next encoded (success or failure) into the client? Or do you want to handle that routing decision on the server?

If it's client-based, then WCF is probably more appropriate, as you are actually moving the controller and the view layers into the client. And the server-side services are purely business and data services, really they are the "domain model".

If you want to control it server-side, then MVC is more likely what you are looking for, as you need a controller, and the "view" layer is split between the client and the server. But the client will have to be written in such a way that it respects what the server is telling it to do. The client becomes a dumb renderer, and the server tells it when to go to a new page.

Answer 3

I would use WCF over MVC simply because with WCF, if you write a proper BO layer, you can easily access that layer from mobile, workflow, winform, etc.etc.etc. all you want. MVC is going to lock you into the paradigm of controllers for actions. I do all of my enterprise scale n-tier apps with WCF (usually exposing both soap and rest bindings) from the same business objects which gives maximum flexibility.