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

Question

NOTE：这不是涉及ServiceStack和WebAPI之间选择的几个问题的重复。

我试图决定在何种程度上我想在我的ASP.NET Web应用程序使用ServiceStack：

选项A：由开沟MVC控制器，并与ServiceStack替换他们全力以赴ServiceStack基于服务和剃刀视图。

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

A的明显优势是增加了灵活性，使我能够构建自己的观点。然而，我关心两件事情：

1. 所有序列化/请求/响应DTO的的反序列化到/从JSON或由ServiceStack执行XML是必然要付出性能为代价相比，纯C＃对象MVC控制器处理。

2. 当处理复杂的对象图时，序列化可能有点片状。例如。在涉及像Parent.Child <-> Child.Parent这样的循环引用的情况下，必须使用IgnoreDataMember属性，否则序列化会打击堆栈。此外，有时反序列化可能会引发难以诊断的模糊的“对象引用未设置”错误。

有没有人对这个困境有什么想法？

Answer 1

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

这听起来并不正确使用ServiceStack时，即可以调用ServiceStack services directly from MVC Controllers这仅仅是一个C＃方法调用，你应该永远不需要做任何非必要的编组/反序列化。

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

这是因为您应该只在线路上发送干净的自描述的DTO，而不是倾销具有循环依赖关系的db模型。