MVC web service in .Net

Question

Is there any use to work in MVC web service instead of asmx and WCF web service. Can anyone please tell the difference between the three?

Answer 1

I'm on the core team that maintains ServiceStack - another very popular choice to build REST-based services on .NET / Mono.

Supports REST, SOAP and MQ based services

In addition to REST-based services you can re-use your same services to Support both SOAP and REST-based endpoints. ServiceStack also includes the .NET's fastest JSON, JSV and CSV text serializers. Here's an earlier answer comparing its advantages over WCF and WebApi.

Succinct, Typed, End-to-end API

ServiceStack also includes typed generic ServiceClients in all the major supported formats including: JSON, XML, JSV, SOAP 1.1/1.2 as well as the super fast binary ProtoBuf and MessagePack formats.

ServiceStack's generic service clients offer the most succinct, typed end-to-end client/server API without any code-gen.

ServiceStack Overview slides

The ServiceStack Overview Talk at this years MonkeySpace has a good intro into ServiceStack and its advantages.

Answer 2

This is a subjective question and with regards to the difference between the 3; WCF is more suited to communication between layers, asmx is basically what we used before wcf came along and due to the flexibility of mvc, it can be used in a number of senarios. WCF is however great for implementing OData services.

I personally use MVC to implement the web service on the client tier for AJAX interactions and have done so on several projects. The advantages are that I do not have a separate project and as such the front end stack is light weight and DRY, more efficient and organising code in this way makes more logical sense to me.

IMHO wcf has too large an overhead and is overly complex for simple JSON serialization. I personally think there is a case for using MVC in an n-tier architectural site instead of WCF.

This article looks at using this in the infamous NerdDinnerd project nerd dinner rest

There are several frameworks such as OpenRasta, but I find that the standard mvc.net tools are more than sufficient.

Also, a good article by haacked here: haacked.com

Answer 3

I can't top the other post on here regarding the merits of WCF over ASMX, it is from the source (microsoft), what I would add to that post as it fails to mention the MVC Web API, is this... your question really depends on the problem you are trying to solve. If you are trying to do messaging, message queues, or lower level tcp/ip it will still be WCF..

I'm a modern world programmer, as lazy as they come.. both ASMX and WCF technologies are starting to feel a bit dated to me, for example a typical WCF implementation will probably have a hefty XML configuration associated to it, if this is the way you are used to working then it will probably feel natural.

I like type safety and hate magic strings and further hate digging around in large XML, to my mind this is the path of the runtime error.

If you have used the MVC framework to create a web application then there is pretty much a zero learning curve to using the mvc webapi.

All the standard things like routes, models and controllers still apply in exactly the same way, all the HTTP verbs are there to be used...

With minimal effort all your routes and controllers can be used in a completely type safe way (no strings), so if it is broken then it probably doesn't compile....

Also it is much easier to write a unit test to exercise a controller than it is to unit test a ServiceContract

I'm not certain but I'd expect the MVC route to lend itself to IoC/DI better than WCF for the same reason above, but I'm prepared to be wrong on that.

Can you tell I'm biased.

Answer 4

About WCF web services and ASPNET Web Services (ASMX), You can find side by side comparision from MSDN : Comparing ASP.NET Web Services to WCF Based on Development

If you are making MVC Application you can use both ASMX and WCF web services, But I strongly recommend to use WCF Web service for any new development.

For information, I think the more suitable Blog regarding comparison is : ASMX Vs WCF

WCF vs. ASMX

Protocols Support

WCF

• HTTP
• TCP
• Named pipes
• MSMQ
• Custom
• UDP

ASMX

• HTTP only

Hosting

ASMX

• Can be hosted only with HttpRuntime on IIS.

WCF

• A WCF component can be hosted in any kind of environment in .NET 3.0, such as a console application, Windows application, or IIS.
• WCF services are known as 'services' as opposed to web services because you can host services without a web server.
• Self-hosting the services gives you the flexibility to use transports other than HTTP.

WCF Backwards Compatibility

• The purpose of WCF is to provide a unified programming model for distributed applications.
• Backwards compatibility
• WCF takes all the capabilities of the existing technology stacks while not relying upon any of them.
• Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed.
• Existing applications are able to upgrade with WCF
• New WCF transacted application will work with existing transaction application built on System.Transactions

WCF & ASMX Integration

• WCF can use WS-* or HTTP bindings to communicate with ASMX pages

Limitations of ASMX:

• An ASMX page doesn’t tell you how to deliver it over the transports and to use a specific type of security. This is something that WCF enhances quite significantly.
• ASMX has a tight coupling with the HTTP runtime and the dependence on IIS to host it. WCF can be hosted by any Windows process that is able to host the .NET Framework 3.0.
• ASMX service is instantiated on a per-call basis, while WCF gives you flexibility by providing various instancing options such as Singleton, private session, per call.
• ASMX provides the way for interoperability but it does not provide or guarantee end-to-end security or reliable communication.