在MVC中选择一致的Ajax响应方法

时间:2016-10-03 00:54:45

标签: javascript ajax asp.net-mvc razor

95%的时间,我将部分视图返回到ajax请求,将响应放入现有HTML中的预定义位置。

但是现在我想要开发一种对ajax响应的一致方法,并且局部视图系统不会一直切割芥末(例如,如果我想在响应中显示附加数据或错误消息)。

我在以下3种方法之间摇摆不定,各有利弊。

我选择哪一个将对我的基本模型,构建JS插件的方法等产生重大影响。由于我将在整个网站范围内部署该方法,因此ajax响应的数据足迹并非无关紧要

我想从更多经验丰富的开发者那里得到反馈:

  • 确认/反驳/加入我看到的优点/缺点
  • 要避免的任何陷阱或陷阱?
  • 我犯了错误 - 例如有没有办法避免使用'?
  • 您是否在MVC应用中使用了这些方法?你发现哪些是最好的,为什么?

1。返回HTML PartialView

赞成

  • 快速且易于实施
  • 非常合身,充分利用MVC内置的模块化和剃刀模板
  • JS中的响应处理可以保持一致和标准化 - 我们始终处理HTML结果

缺点

  • 无法提供其他数据或错误反馈
  • 一般不灵活
  • 效率不高

2。将HTML作为JSON响应的一部分返回

赞成

  • 最全面,最灵活的选项
  • 可以使用剃刀模板化视图,同时允许其他数据
  • 如果我们使用response.Errorsresponse.SuccessHtml等,JS中的响应处理可以部分标准化。

缺点

  • 实施最复杂 - 需要在控制器外渲染剃刀视图
  • 据推测,它是最昂贵的'选项 - HTML的模板视图和物理上响应中的大多数数据的开销

第3。返回纯JSON响应 - 无HTML

赞成

  • 数据大小方面的最快响应
  • 我看过推荐这种方法(不记得在哪里)

缺点

  • 不是很MVC-ish - 是的,我们可以使用小胡子或类似的模板,但重用与普通页面加载相同的剃刀视图会更好
  • 如果我们想在视图中开始使用if / else语句和其他逻辑,那么Mustache模板会变得复杂
  • 很少有机会标准化JS响应处理

0 个答案:

没有答案