Asp.net mvc 使用ServiceStack服务与ASP.NET MVC控制器的优缺点？

注意：这不是关于ServiceStack和WebAPI之间选择的几个问题的重复

我正在尝试决定在ASP.NET web应用程序中使用ServiceStack的程度：

选项A：通过抛弃MVC控制器，用基于ServiceStack的服务和Razor视图替换它们，全力打造ServiceStack

选项B：使用支持ServiceStack的MVC控制器以获得更好的性能和可扩展性

A的明显优势在于，它为我构建视图提供了额外的灵活性。不过，我担心两件事：

与MVC控制器处理的纯C#对象相比，ServiceStack执行的从Json或Xml到Json或Xml的所有请求/响应DTO的序列化/反序列化必然会以性能为代价

在处理复杂的对象图时，序列化可能有点不稳定。例如，在涉及循环引用的情况下，如

Parent.Child.Parent

必须使用IgnoreDataMember属性，否则序列化将导致堆栈崩溃。此外，有时反序列化会抛出难以诊断的模糊“对象引用未设置”错误

有人对这个困境有什么想法吗

与MVC控制器处理的纯C#对象相比，ServiceStack执行的从Json或Xml到Json或Xml的所有请求/响应DTO的序列化/反序列化必然会以性能为代价

这听起来不对，在使用ServiceStack时，您永远不需要执行任何不必要的封送/反序列化，也就是说，您可以调用一个C#方法调用

在处理复杂的对象图时，序列化可能有点不稳定。例如，在涉及循环引用的情况下

---

这是因为您应该只在线路上发送干净的、自我描述的DTO，而不是转储具有周期性依赖关系的db模型。

我误解了解释和示例，认为ServiceStack使用与AppHost中指定的格式化程序对应的客户机调用服务。现在，经过更多的阅读，我发现我错了。