can we use WCF in Asp.net MVC and how can we use?
Sure you can - you need to learn the basics, e.g. from this site here:
http://msdn.microsoft.com/WCF
I can't possibly explain all you need to know here - go and learn the basics of WCF, and if you have concrete problems / questions, come and ask them here!
Do you mean, can my ASP.NET MVC projects be WCF clients, or contain WCF servers?
If the former, sure no problem. Right click on Solution Explorer, 'Add Service Reference', enter the URL to a running service (or pick an existing one from within another project in your solution) and away you go.
If the latter, that's fine as well. There is nothing stopping you from adding a WCF service via (perhaps SomeService.svc) 'Add\New Item...' (WCF Service, AJAX-enabled WCF Service, or Silverlight-enabled WCF Service are your options) or by hand. You need to bear in mind that the WCF service in this case will be hosted in IIS so there are some restrictions you need to be aware of depending on which version of IIS you are deploying to (ie. in IIS 6 only HTTP protocols are supported for your WCF services, some of the more esoteric WCF options may also be limited).
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.
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
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.
I have a .NET 4 application that runs as a windows service. It runs periodic tasks and provides WCF restful webservices. It already hosts a silverlight web page (via WCF) that allows a user to configure the service.
Now I have a requirement to provide information on HTML/java script pages (e.g. for browsers and platforms that don't support Silverlight). I can serve simple HTML and javascript pages through WCF but that becomes laborious very quickly. I'd like to use MVC2.
Is it possible to provide MVC2 web pages from within a windows service? Or at least use some of the functionality provided by MVC like routing and the view engine?
Or is it more trouble than it's worth and should I head down the path of a separate app hosted on IIS?
You can host the ASP.NET runtime in any type of application including a Windows Service using the CreateApplicationHost method. Although note that by doing this you lose the robustness, security, logging, etc... that a real web server such as IIS provides.
Since you're asking the question about what route to take, I'd host an MVC2 application in IIS. Why recreate a web server using WCF when IIS is already there - and since you're asking, it sounds like that's a viable option.
I agree with Darin's answer that you can host ASP.NET MVC2 in any application, but I think you're going to end up recreating a lot of plumbing that's already in place with IIS.
On the upside, if you go with serving up ASP.NET MVC2 resources in a WCF service application, it may end up rocking and you could have a nice application you can sell on the side. :)
I have an ASP.NET MVC 1.0 webapp, which serves as a front-end site for our external API. More specifically, it has a Control Panel for our API clients, documentation, etc.
Now I want to move our actual API (which is a set of WCF services) inside this project, so that, for example, http://api.example.com/controlpanel/dashboard would be served by ASP.NET MVC runtime, wherease http://api.example.com/services/1.0/users.svc would be served by an appropriate WCF service.
Granted, this can be done by adding a services/1.0 virtual folder in IIS, but I really want these two parts to be inside one project.
Is this doable at all? If yes, how do I integrate these two beasts?
Turns out MVC/WCF isn't the issue. Services hosted within the MVC app are activated just fine (I guess IIS bypasses the MVC runtime for .svc requests).
The issue was more to do with services in Areas, and requests for .svc files not going through the route table.
I've asked a more specific question addressing the actual problem here.
Expose WCF services that belong to an Area in MVC app at a routed path