Advantages/disadvantages of using ServiceStack services vs ASP.NET MVC controllers?

Question

NOTE: This is not a duplicate of the several questions dealing with the choice between ServiceStack and WebAPI.

I am trying to decide the extent to which I want to use ServiceStack in my ASP.NET web application:

Option A: Go all-out ServiceStack by ditching MVC controllers and replacing them with ServiceStack-based services and Razor views.

Option B: Use ServiceStack-enabled MVC controllers to get better performance and scalability.

The clear advantage of A is the added flexibility it gives me in structuring my views. However, I am concerned about two things:

1. All the serialization/deserialization of request/response DTO's to/from Json or Xml performed by ServiceStack is bound to come at the cost of performance compared to pure C# objects that MVC controllers deal with.

2. Serialization can be somewhat flaky when dealing with complex object graphs. E.g. in cases involving circular references like Parent.Child <-> Child.Parent one must use the IgnoreDataMember attribute, or else serialization will blow stack. Also, sometimes deserialization can throw obscure "Object reference not set" errors that are very hard to diagnose.

Does anybody have any thoughts on this dilemma?

Answer 1

All the serialization/deserialization of request/response DTO's to/from Json or Xml performed by ServiceStack is bound to come at the cost of performance compared to pure C# objects that MVC controllers deal with.

This doesn't sound right you should never need to do any un-necessary marshalling/de-serialization when using ServiceStack, i.e. you can call ServiceStack services directly from MVC Controllers which is just a C# method call.

Serialization can be somewhat flaky when dealing with complex object graphs. E.g. in cases involving circular references...

That's because you should only be sending clean, self-describing DTO's on the wire, not dumping db models with cyclical dependencies.