Suggested approach for creating asp.net MVC and WCF service application

4
votes

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.
2
asp.net-mvcajaxwcf

2 Answers

1
votes

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.

1
votes

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.