Should ServiceStack be the service layer in an MVC application - http://stackoverflow.com/a/10572977

181 views
Skip to first unread message

Carlos Mendes

unread,
Dec 7, 2012, 7:15:38 PM12/7/12
to servic...@googlegroups.com
Hi,

I was reading this answer on SO and the recommended approach is actually to have both MVC and SS sharing pure C# dependencies.

In a scenario where we want to make an app available as an API I think it could be simpler to call  SS services from MVC controller.

What are the drawbacks (design, abstraction, performance) of Calling ServiceStack services from an MVC Controller? 

public HelloController : ServiceStackController {
    public HelloService HelloService { get; set; } //Autowired

    public void Index(string name) {
       ViewBag.GreetResult = ((HelloResponse)HelloService.Get(name)).Result;
       return View();
    }        
}


Demis Bellot

unread,
Dec 8, 2012, 4:24:22 AM12/8/12
to servic...@googlegroups.com
Abstraction is a matter of taste, it's basically what you see is what you get. I like encapsulating my services in ServiceStack services for maximum re-usability.

There was one thing missing in the above which was to inject the current RequestContext which is needed for services that make use of base.Request or base.Response in the Service. I've updated the question to include the recommended way to call a ServiceStack service.

public HelloController : ServiceStackController {

  public void Index(string name) 
  {
    using (var helloService = AppHostBase.Resolve<HelloService>())
    {
       helloService.RequestContext = System.Web.HttpContext.Current.ToRequestContext();

       ViewBag.GreetResult = ((HelloResponse)HelloService.Get(name)).Result;
       return View();
    }
  }        
}

The is also similar to the recommended way of calling another service in ServiceStack: http://stackoverflow.com/a/13710403/85785 (just uses a convenience method on the base class to do the same thing).

As for the performance overhead, it's effectively not much more overhead then calling a normal C# method because that's effectively all that it's doing, i.e. Resolving an Autowired service from the IOC (if you use the built-in Funq this is near native speed), assigning the current RequestContext and then calling a C# method.
Reply all
Reply to author
Forward
0 new messages