I have been using WCF for my web applications as it has the vast features of supporting multiple protocols, hosting with or without IIS and many other features though it is little confusion in understanding the configurations (ABCs) at client & server sides especially in terms of message sizes.
Though I haven't implemented applications using WebAPI but has got an idea as how it does the miracles with HTTP
I however need to decide for my new mixed mode application where the Service layer is common for both Mobile & Web based requests.
I do keep hearing about MVC6 but not sure how would it fit for my requirement.
So, trying to understand which one is more Apt for the requirement. Is this WCF or Web API or MVC6
Appreciate your master suggestions and thanks in advance.
Related
I have a standard nteir setup :-
Web server -> App server -> DB server
I have an MVC 5 web application sitting on the web server with controllers calling a WCF services project sitting on the App server. WCF services project uses EF6 to marshal data on the DB server.
I am wondering if WCF is overkill? Is there is an easier way to achieve this same architecture? I am thinking I should have gone with Web API on the app server and then just call the web API from the controllers with the HTTPClient?
Or, I could even just use a plain MVC project on the App server returning JSONResults to the MVC controller on the web server?
It depends...
You have to understand what are the benefits of each set up. This is not exhaustive, just a quick brain dump. This should give you some hints to look further as in the wild world there might be many more reasons for choosing one or another solution.
Why WCF. Are you going to have different clients to your backend ? You need some entreprisy security between clients and you backend ? With WCF you could configure Http, TCP endpoints, set message or transport security and a lot more. It could be needed for example if your doing an intranet application and you would like not only to have your UI (MVC application) but other systems going to it. If this is not needed WCF seems overkill here.
Web Api is also agreat choice if you would like to built more REST oriented api, enabling content-negotiation for different clients (different media-types). Building REST is not about issuing JSON, it's much more and this would be too long to explain it here. If your client is not only your MVC app, but you could have a need for a api for other mobile devices, OAuth authentication and the so, this could be a good way to do.
Plain MVC app would also fit if you don't have any special needs, go for it. No overhead needed. Keep It Simple And Stupid.
I hope this helps
I would not change this.
WCF is a good choice for communication between Web Tier and App Tier. I would never put my App Tier exposed to outside world, so if there is any communication to my app from outside world, it would be through Web tier only and if there is a need to support multiple clients, I would create a WebAPI on web tier and expose that.
I would keep App tier only available to Organization internal and with WCF I would have flexibility to write service code and contracts which can then be exposed over various bindings (transport, security, etc.).If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF is indeed a good choice.
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?
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.
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.
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
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.
In the last few years, I have seen the rise of many Web APIs - services exposed over plain HTTP rather than through a more formal service contract (like SOAP or WS*). Microsoft has just launched a new framework called "ASP.NET Web API" hat makes it easy to build HTTP services that reach a broad range of clients. Event if I am a .net fan, it is another communication framework (after asmx, wcf, ria, ...). Now, working as an happy architect, I have to take decision over technologies.
Is Asp.net Web Api really a good choice for a new architecture? Remember Linq2Sql, I do not want to invest in a "disposable" api.
Is there still a use for WebBindings in WCF?
The problem with this question, in terms of it being a stack overflow question, is that it's basically subjective. As a result, I'm pretty sure it'll be closed - but I'm going to stick my 2 pence (it's more like £2 actually) anyway and if it gets closed so be it.
First Linq2Sql isn't 'disposable' - it's still there and not going to go away. It's not being developed - that's another matter entirely.
Anyway - The Asp.Net Web API is a formalization of REST web service support by many people from the same team that work(ed) on Asp.Net MVC and uses a very similar approach to extensibility, pipelining, cross-cutting concerns (e.g. authentication, logging, validation) and such. Whether you use it or not is entirely down to whether you are intending to develop RESTful web services. If you are, and you're on .Net 4+, then, in my opinion, you'd be mad not to.
The overall architecture in the Web API is very good and you can extend most of it without too much effort at all. In particular, the way that they have handled content negotiation is very very nice, making it trivial to, for example, support JSON requests but returning XML responses just because a client sends Content-Type:application/json and Accepts:application/xml.
As a server technology it's also very very fast; partly because it's entirely asynchronous (increasing scalability) but also because the stack between a request coming in, to your code being called, is very shallow.
Not only that but you can host it in both IIS and in any .Net application also - which increases your hosting options but also makes it a candidate for intra-network communications within a common network (i.e. non-internet) environment.
If, however, you want to write a SOAP or WS-HTTP service then, no, the Web API is not for you - you'd stick with WCF.
In short - you need to think of the Asp.Net Web API purely as a server and client technology running on .Net as opposed to a protocol or web architecture. It enables you to build RESTful web services - you can also do that in MVC, WebForms (if you really wanted to), .ashx handlers, or by writing your own HttpListener.
Which of those you choose is entirely up to you to decide.
We can call ASP.NET Web API a replacer of WCF Web API.
It will support more platform oriented service.
I have a database on a database server. No web service in place to be consumed by a web application.
If I want my iOS app to communicate with a database server (send & receive data), I know I can create a web service and then call that service from my iOS app. But what web service is recommended for this? Should I just write a .asmx web service in .NET or should I go for MVC WEB API or may be go for WCF ?? I have spend hours doing research on this. Please help.
A lot will depend on where you expect the service to be hosted, and what technology stack(s) are supported by the host. If you are self-hosting, then do whatever works in the technologies you know and understand. If you want to use a host that targets its services to small-to-midsize independent development teams, many providers like Heroku support things like Rails services. PHP is always an option as well. Microsoft-based solutions and Java-based solutions tend to be more widely used in larger enterprises and data centers, and if that's where you'll host your service then these would also be good options. And of course I'm speaking in broad generalities here: For any general trends I might list here there are lots of exceptions where other approaches make sense.
If you'd rather let the decision be driven by what makes things easiest for your iOS code, I would recommend you start with server-side technologies that support REST-ful interfaces using JSON to represent your service's resources. REST-ful services are very easy to consume from iOS, and JSON-based representations of resources are very easy to parse and produce in Objective-C.
I am personally used this approach to set a direction for my app. For the service side, I am going with a Rails implementation of REST-ful web services. I'm a Java developer by profession, but for a small independent project the options for hosting Java services were more limiting than with Rails so I've picked up rails on the side to make my project work. So far it's suited my project quite well.
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.