Proposed approach for creating asp.net MVC and WCF applications

Question

I am working on a web service that will have both its own WPF client and a Javascript-based web interface.

While I was working on the WPF service and client, the WCF service was a stand-alone WCF service project for IIS and works fine. Now that I'm starting to work seriously in the web interface, I wonder if keeping a separate WCF service is a good choice.

After reading on this subject, there seem to be many options; For example, I could:

• Separate two projects
• Build an asp.net MVC website and add Ajax-enabled WCF service to the project
• Build the asp.net MVC website and add the WCF service to the project.
• Create a WCF service library project and place it in an MVC application (not quite sure about this, but it seems possible)

And I have such a feeling, probably more.

What are you suggesting me to do? My goals:

• Accessing a service with a WCF client using a service link, as I have done so far
• Access the service from Javascript in the web interface
• Access to the service using port 80 from Javascript and the WCF client (to avoid problems with the firewall).
• The presence of a website and service in the same domain
• The ability to run the application using shared hosting (Gearhost) without multiple virtual IIS directories / applications.

Answer 1

In the end, I decided to create three projects: the service interface, dll services and data contracts, the service library itself, which refers to the interface and the website, the MVC application in which the created service library is located. MVC code interacts with the service as if it were hosted on another system using a client proxy (which in this case connects to itself, oddly enough). This should allow me to place all this in one virtual directory, while maintaining a not-too-painful decoupling along the line, if necessary. To preserve the order of things, I create a service proxy manually in the code, referring to the DLL-interface and NOT using the function "add service link".

Answer 2

Recommended: I would suggest keeping projects as separate as possible. This allows more flexibility in how everything can be hosted if your application crashes and you need to split into different server / application pools, etc. In addition, separation of concerns is one of the principles of service-oriented architecture (SOA). This will force you to encode your service in such a way that it is "shared", which could facilitate reuse in the future. Forgive me if this is lower than you, but I have to say this: in the visual studio you can create an empty solution and add it to each of your individual projects so that you work in one copy of the visual studio.

Then in your IIS instance you will have something like this:

/ = root app /servicelayer/ = virtual application 

But ... you have a goal: "The ability to run a thing using shared hosting (Gearhost) without multiple virtual IIS directories / applications." You cannot host individual asp.net applications in the default IIS directory without placing them as virtual applications. This means that you cannot simply paste the servicelayer application folder into the root folder of the application.

Due to this requirement, the only option you have is to add the service code to your asp.net mvc application. I would create a folder called "/ services /" that contains all your endpoints so that it spreads slightly. Then add the Ajax-enabled WCF service to this folder.