asp.net-mvc – 当您使用带有淘汰赛的JS视图模型时,MVC有什么地

发布时间：2020-12-16 07:00:58 所属栏目：asp.Net 来源：网络整理

导读：我最近一直在进行一些讨论,讨论的内容是转移到ASP.NET MVC和Knockout,以便将来在一个当前ASP.NET Web表单的产品上工作.该产品具有SPA的一般当前定义的许多特征. 当你开始使用JS视图模型生成所有视图时,我从来没有看到MVC实际上是如何适应的,这些模型从调用JS

我最近一直在进行一些讨论,讨论的内容是转移到ASP.NET MVC和Knockout,以便将来在一个当前ASP.NET Web表单的产品上工作.该产品具有SPA的一般当前定义的许多特征.

当你开始使用JS视图模型生成所有视图时,我从来没有看到MVC实际上是如何适应的,这些模型从调用JSON Web服务获取数据.

是否存在利用Knockout w / JS模型和JSON以及MVC框架的最佳部分的“最佳位置”？

以下是我一直在考虑的一些事情(有点随机 – 只是看看我是否可以激发一些讨论/答案)：

>你什么时候使用Knockout vs. Razor？ Knockout在客户端浏览器上运行时生成视图元素.在客户端收到响应之前,Razor作为服务器请求的一部分运行.是否有时候一个明显比另一个好,还是归结为个人品味？
>为了完成代码,在C#/ Razor的幌子下保留更多代码是否有价值？此外,当抛出异常时,堆栈跟踪到编译的代码似乎比JS调试更容易.
>通过创建空白的ASP.NET应用程序和独立的Web API项目,将视图与后端完全分离是否更好？

解决方法

很多很棒的问题,我将分享我对这些主题的一些看法. (问题已被解释)：

1)在Knockout世界中有MVC的位置吗？ – 当然. MVC不仅仅是Razor.服务器端路由,区域,身份验证等都由MVC提供.所以在我看来,我仍然可以将MVC用于所有“管理和组织”,但我的所有视图仍然主要(但不一定完全)是AJAX驱动的.我以前在SO上讨论了using MVC and KO together.我还在WintellectNOW dot com上有一个专门讨论该主题的视频.

2)什么时候应该使用剃刀？ – 让我们实际上切换术语.它真的不是关于Razor vs. Knockout：它实际上是关于服务器端和客户端渲染.
那么什么时候应该使用服务器端渲染？一个理想的时间是在加载数据时,只需要在页面初始化时执行一次.例如,如果您有一个用于下拉列表的状态列表,并且该列表极不可能更改,请继续并在服务器端加载该列表.为什么在这种情况下转身并向API发回另一个请求？我会保留那些对动态或上下文敏感数据的调用.

3)为了加工目的,在C#中保留更多代码是否有价值？ – 恕我直言,没有.调试JS确实很痛苦,但这并不足以让我无视客户端所能做的所有令人敬畏的事情.值得偶尔沮丧的是提供更好的用户体验.

4)我应该将Web API移动到另一个项目以保持代码分离. – 这完全取决于项目的需求.如果Web API项目要为多个应用程序提供服务,那么YES应该在一个单独的项目中.这也将它放在一个单独的DOMAIN,SUB,PORT或其他东西上,以区别于其他Web应用程序.这样做会引入跨源资源共享(CORS)问题.除非绝对必要,否则CORS是一个我不会经历的特殊地狱.如果您的Web API只是为您的单个Web应用程序提供服务,请帮自己一个忙,并将其保存在同一个项目中.

和其他一切一样,很多都归结为个人偏好.我的目的是使用服务器端来管理我的应用程序的大局,以及所有UI / UX的客户端.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!