MVC with Service architecture

MVC Controllers should be thin route drivers. In general your controller actions should look similar to

[Authorize(Roles = "User,Admin"]
[GET("hosts")]
public ActionResult Hosts(int id)
{
    if (false == ModelState.IsValid) 
            return new HttpStatusCodeResult(403, "Forbidden for reasons....");

    var bizResponse = bizService.DoThings();

    if(bizResponse == null) return HttpNotFound(id + "could not be found")

    if(false == bizResponse.Success) 
        return new HttpStatusCodeResult(400, "Bad request for reasons....");

    return View(bizResponse);
}

You can also generalize the model state checking and response object checking (if you use a common contract - base type or interface) to simply have:

[Authorize(Roles = "User,Admin"]
[GET("hosts")]
[AutoServiceResponseActionFilter]
public ActionResult Hosts(int id)
{
    var bizResponse = bizService.DoThings();

    return View(bizResponse);
}

I am a proponent of using serialization to pass from the business layer to the http/MVC/ASP.NET layer. Anything that you use should not generate any http or tcp requests if it is in-process and should used named-pipes for in memory transport. WCF with IDesign InProcFactory gives you this out of the box, you can't emulate this very well WebApi, you may be able to emulate this with NFX or Service Stack but I am not sure off hand.

If you want the bizService to be hosted out of process the best transport at this point is to use a Message Bus or Message Queue to the bizService. Generally when working with this architecture you need a truly asynchronous UI that once the http endpoint accepts the request it can immediately receive the http OK or http ACCEPTED response and be informed later of the execution of the action.

In general a MVC controller / ASP.NET http endpoint should never initiate a http request. Your bizService if necessary is free to call a third party http service. Ultimately roundtrip network calls are what kills the perceived performance of everything. If you cannot avoid roundtrip calls you should strive to limit it to at most one for read and at most one for write. If you find yourself needing to invoke multiple read and multiple write calls over the wire that is highly illustrative of a bad architectural design of the business system.

Lastly in well designed SOA, your system is much more functional than OO. Functional logic with immutable data / lack of shared state, is what scales. The more dependent you are on any shared state the more fragile the system is and starts to actively become anti-scale. Being highly stateful can easily lead to systems that fracture at the 20-50 req/s range. Nominally a single server system should handle 300-500 req/s of real world usage.

The reason to proxy business services such as this is to follow the trusted subsystem pattern. No user is ever able to authenticate to your business service, only your application is able to authenticate. No user is ever able to determine where your business services are hosted. Related to this is users should never authorize to business service itself, a business service action should be able to authorize the originator of the request if necessary. In general this is only needed for fine grained control such as individual records can be barred from a user.

Since clients are remote and untrustworthy (users can maliciously manipulate them whether they're javascript or compiled binaries) they should never have any knowledge of your service layer. The service layer itself could literally be firewalled off from the entire internet only allowing your web servers to communicate to the service layer. Your web server may have some presentation building logic in it, such as seeding your client with userId, name, security tokens etc but it will likely be minimal. It is the web server acting as a proxy that needs to initiate calls to the service layer

Short version, only a controller should call your service layer.

One exception, if you use a message queuing system like Azure Service Bus for example, depending on security constraints it could be fine by your UI to directly enqueue messages to the ASB as the ASB could be treated as a DMZ and still shields your services from any client knowledge. The main risk of direct queue access is a malicious user could flood your queue for a denial of service type attack (and costing you money). A non-malicious risk is if you change the queue contract out of date clients could result in numerous dead letters or poison messages

I really believe the future of all development are clients that directly enqueue messages but current technology is very lacking for doing this easily and securely. Direct queue access will be imperative for the future of Internet of Things. Web servers just do not have the capacity to receive continuous streams of events from thousands or millions of light bulbs and refrigerators.