I am working on a web service which is going to have both a native WPF client as well as a Javascript based web interface.
While I was working on the service and WPF client, the WCF service has been an IIS hosted WCF service project of its own, and has been working fine. Now that I'm starting to work in earnest on the web interface, I am wondering if keeping the WCF service separate is a good choice.
Reading around on the subject, there seem to be lots of options regarding this; for example, I could:
Keep the two projects separate
Create the asp.net MVC website and add an Ajax-enabled WCF service to the project
Create the asp.net MVC website and add a WCF service to the project
Create a WCF service library project and have that hosted in the MVC application (not entirely sure about this, but it seems possible)
And I have a feeling there's probably more.
What do you suggest I should do? My goals are:
Accessing the service from the WCF client using a service reference like I have done so far
Accessing the service from Javascript on the web interface
Accessing the service using port 80 from Javascript and the WCF client (to avoid firewall issues)
Having website and service under the same domain
Being able to run the thing using shared hosting (Gearhost), without multiple IIS virtual directories/application starting points.
Recommended: I would suggest keeping the projects as separate as possible. It allows more flexibility in how everything can be hosted if your app takes off and you need to separate to different servers/app pools/etc. Also, separation of concerns is one of the Service Oriented Architecture (SOA) tenets. This will force you to code your service in a way that is "generic" enough that might promote re-useability down the line. Forgive me if this is below you but I need to say it: In visual studio you can create an empty solution and add in each of your individual projects so you are working all within one instances of visual studio.
Then in your IIS instance you would have something like this:
/ = root app
/servicelayer/ = virtual application
But... you have a goal of "Being able to run the thing using shared hosting (Gearhost), without multiple IIS virtual directories/application starting points." You cannot host separate asp.net applications within a default IIS directory without marking them as virtual applications. This means you can not just paste the servicelayer application folder into your root application folder.
Because of that requirement then the only option you have is to add your service code into your asp.net mvc application. I'd create a folder called "/services/" that houses all your endpoints so that it's slightly separated. Then add an Ajax-enabled WCF service to that folder.
In the end I decided to create three projects: the service interface, a dll holding service and data contracts, the service library itself, which references the interface, and the website, an MVC application which hosts the created service library. The MVC code interfaces with the service as if it was hosted on a different system, using a client proxy (which in this case connects to itself, funnily enough). This should allow me to host the whole thing in a single virtual directory while still providing for not-too-painful decoupling down the line if need be. To keep things tidier, I am creating the service proxy manually in code by referencing the interface dll and NOT using the "add service reference" function.
Related
I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
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 it possible to host in the same appDomain two different projects of WCF service and MVC application?
For example, I need to use some pulic static class from MVC application by my WCF service. But they are in different projects, so this class for them is in different appDomains.
It is quite common to host WCF services within an ASP.NET application (MVC or WebForms). From a coding perspective, the only thing you may need to configure is ASP.NET compatibility mode, if the code WCF is calling requires access to the current HTTP context.
Create your WCF service contracts, and implementations of those contracts, configure your services, bindings, and behaviors in the web.config, as you normally would. Here is another example, which you could create in virtually any ASP.NET application.
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).
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