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

Question

注意：这与处理ServiceStack和WebAPI之间选择的几个问题不重复。

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

选项A ：通过放弃MVC控制器并使用基于ServiceStack的服务和Razor视图替换它们来全力以赴的ServiceStack。

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

A的明显优势在于它为我构建视图提供了额外的灵活性。但是，我关注两件事：

1. 与MVC控制器处理的纯C＃对象相比，ServiceStack执行的对JSON或Xml的请求/响应DTO的所有序列化/反序列化都将以性能为代价。

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

有没有人对这种困境有任何想法？

Answer 1

  

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

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

  

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

那是因为你应该只是在线上发送干净的，自我描述的DTO，而不是倾销具有周期性依赖性的db模型。