使用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时你永远不需要做任何不必要的编组/反序列化,即你可以直接从MVC控制器调用ServiceStack服务,这只是一个C#方法调用.

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

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