As far as writing one application that leverages both ASP.NET/MVC and WCF, its not great. WebAPI may have improved matters, but in one project I am familiar with that was using WCF and MVC in the same app, they ended up maintaining two different sets of models to represent the same concepts - one for the WCF code and one for the MVC code. You can imagine all the mappers they had to write to translate things between the two models - there were lots of lines of code there that could have / should have been avoided.
Part of why this happened is that WCF request and response objects should be annotated with [DataContract] and their properties with [DataMember], while MVC does not require this. Idiomatic MVC on the other hand is going to want ViewModels, which have different goals than WCF DataContracts. Of course, its possible that the use of two full sets of domain objects had more to do with Conway's law than WCF & MVC conflicting, but it's worth pointing out that WCF and MVC have different goals and requirements as far as output and input.
Personally, I'm partial to developing a simple but powerful services oriented back end API, particularly when you might want multiple clients. I think the advent of excellent JavaScript MVVM and micro- MVC frameworks makes this a natural choice, as writing application code using BackboneJS, KnockoutJS and others allows for a capable development environment. You can then consume the back end in the micro MVC of your choice to build your web app, or on a mobile client, and your partners might consume the same API remotely as well.
Suggestion
Either WebAPI or Service Stack might be good candidates for building your back end API. I recommend Service Stack, as I've been using it for the last few months and have found it to be an excellent replacement to WCF. I'm currently writing a tutorial series on service stack on my blog.
The group maintaining service stack has posted an example application using the framework to develop a StackOverflow like clone which shows a development pattern that I believe is especially compelling. It involves a simple, model based services back end that you could imagine being consumed by an MVC website, a mobile app, or just about anything else easily. ServiceStack's design goals clearly encourage a pattern that should lead to less coupling between client and server. The idea is to avoid chatty API's with calls like GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm) in favor of fewer methods. You might implement the same thing in service stack like this:
[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers
{
public int? RegionId { get; set; }
public string SearchTerm { get; set; }
}
public class CustomersService : Service
{
public object Get(Customers request) {
// handle request
return new CustomersResponse();
}
}
The benefit, to my eyes, is that instead of having your business logic spread out over lots and lots of separate methods GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), it's all in one place. This should lead to more maintainable code.
Coincidentally, Stack Exchange hired the original Service Stack author. He continues to commit actively to the Service Stack project.
I am particularly fond of message queues for certain things - and while WCF allowed for this, WebAPI does not. ServiceStack does allow the same web service to be invoked via MQ. For more info on this see the Redis MQ Host at: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis