现在做一个应用，总想用html 加webapi(或mvc做后台返回数据），不知道这想法可否？

[qq_18536211]

总觉得asp.net mvc 请求一个页面，由ACTION返回，服务器总会有不少“负担”，需解释这页面再送给访问前端。
因此，想在MVC中，前端全用html文件（相当web服务器），请求的是HTML文件（js)，通过JAAX 请求MVC或API得到数据 ，真要这样做有什么缺点？（用户验证？）
请行家指教！

[以专业开发人员为伍]

引用 21 楼 qq_18536211 的回复:

我目前只是想，如果用WEBAPI做后端，为前端提供数据(json），但不喜欢WEBAPI这种默认的路由方式，觉得不明了。用'MVC',来做后端，又觉得许多用不上，是不是性能没WEBAPI快，

纯前端框架，只访问数据服务，这方面在 .net 中封装比较复杂的（为初学者省去了 json 序列化和反序列化的几行代码）就是 WebApi，而如果你对于传统的 http 机制学过的话，轻量级地用 ashx 方式会觉得已经非常方便了。 asp.net mvc 是一个产品名词儿，里边混杂了 webapi、路由、WCF、甚至 websocket 等等与 MVC 界面框架无关的内容。所有有的人生怕我们将 asp.net mvc 中哪些是 MVC、那些不是 MVC 给区分出来。 你说的”为前端提供json数据“的模式，这样你的前端控制 MVC 或者 MVVM，根本不用管后端还去纠结什么表现层编程技术问题了，完全扔掉了。 路由确实是牺牲性能的。asp.net 并不是对所有的东西都用路由。并且你可以自己写上几十行代码、写一个 ashx 来自己封装服务器端服务对象的解析层，肯定会比”路由+webapi“更快、更清晰、更方便”。

[以专业开发人员为伍]

我给你举一个例子，简单地 ashx 可以这样初步理解

public class Handler1 : IHttpHandler
{

    public void ProcessRequest(HttpContext context)
    {
        var request = context.Request;
        using (var reader = new StreamReader(context.Request.InputStream))
        {
            var text = reader.ReadToEnd();      //断点调试这里，可以得到客户端的所有提交的 string
            var obj = JObject.Parse(text);      //从收到的 string 转换为 Json 格式
            var commandName = (string)obj["ServiceName"];
            switch (commandName)
            {
                case "调用功能A":
                    方法A(obj, context);  //传入整个 obj 以及 context，后者用来 Respose。
                    return;
                case "调用功能B":
                    var result = 方法B(obj["data"]);
                    将result进行json序列化并通过context.Response输出;
                    return;
                default:
                    Type t = dictionary[(string)obj["serviceName"]);   //dictonary 是初始化好的服务功能名与类型对应的字典
                    HMyCommand h = (HMyCommand)Activator.CreateInstence(t);    //你为所有的服务都实现了一个通用的接口
                    h.Execute(obj["data"], context);                  
                    return;
            }
        }

    }

这类，你可以自己取得客户端上行的 json 格式的数据，使用自定义通用的服务模式，取得结果并返回 json 格式的结果。你可以自己插入自己的中间处理环节，例如缓存等等，自由插入自己想集成的操作，不用考虑什么路由功能。

[以专业开发人员为伍]

一个纯前端的 web 企业级应用程序，运行几小时，也不访问别的页面。所以说“解决浏览器地址请求”这就说明还是那种一遍遍切换页面的思路。 纯前端的应用程序是单页面的。你可以说一个单页面的程序跳转刷新到另外一个单页面的程序，这就回到了传统的 asp.net 机制。这个时候我们用 url 参数传一些数据，用 Session 集合来缓存一些数据，作为 web 应用程序的跳转之间桥梁。过去的 asp.net “页面”概念就是现在的纯前端的"应用程序"概念，这就是一个重大的改变。只有理解到这样，知道一个页面打开之后几个小时都不跳转刷新（同时还跟桌面程序一样会展现几十种不同的页面交互操作界面），这就能理解为什么说 MVC、MVVM之类的表现层的设计名词儿在现在 asp.net 中其实根本没有涉及到。asp.net 中没有前端技术框架（只不过是2005年左右在asp.net 里边引用了一个 jQuery 文件、现在又引用了 bootstrap 等而已），前端技术需要认真学。 一个 asp.net 程序员来说因为 asp.net mvc 所以自己会前端开发，这可要找不到工作了。

[jianghupt]

引用 22 楼 以专业开发人员为伍 的回复:

我目前只是想，如果用WEBAPI做后端，为前端提供数据(json），但不喜欢WEBAPI这种默认的路由方式，觉得不明了。用'MVC',来做后端，又觉得许多用不上，是不是性能没WEBAPI快，

纯前端框架，只访问数据服务，这方面在 .net 中封装比较复杂的（为初学者省去了 json 序列化和反序列化的几行代码）就是 WebApi，而如果你对于传统的 http 机制学过的话，轻量级地用 ashx 方式会觉得已经非常方便了。 asp.net mvc 是一个产品名词儿，里边混杂了 webapi、路由、WCF、甚至 websocket 等等与 MVC 界面框架无关的内容。所有有的人生怕我们将 asp.net mvc 中哪些是 MVC、那些不是 MVC 给区分出来。 你说的”为前端提供json数据“的模式，这样你的前端控制 MVC 或者 MVVM，根本不用管后端还去纠结什么表现层编程技术问题了，完全扔掉了。 路由确实是牺牲性能的。asp.net 并不是对所有的东西都用路由。并且你可以自己写上几十行代码、写一个 ashx 来自己封装服务器端服务对象的解析层，肯定会比”路由+webapi“更快、更清晰、更方便”。[/quote] ------------------------ ashx这个东西是必须IIS的才能运行，说明你的思路还是局限在 windows 平台下面，并没有你自己高谈阔论的所谓 不局限于语言，不局限于某个框架，自己去写等等。 而实际上你可能不知道的是 .Net 下的MVC也是通过ProcessRequest来流转程式的。 微软为了解决这个痛点，所以才搞出了跨平台的 Core MVC 。 Ashx这个东西无论对升级，对版本更新，对开发并没有好处，除了你自己去玩玩。否则微软十年前就直接推送 ashx就行了，何必后来的webform , .net mvc,以及现在的core mvc ? asp.net mvc 和 MVC几乎没什么区别， MVC是为大型项目而生，.net mvc这也是遵循这一规则 假如按照你说的，什么玩意都自己搞，不遵循微软推送的标准 技术库， 那你还要微软干吊？你不如自己玩去算了。 至于路由这个东西，并不是MVC 独有的，很久之前就有。性能上肯定有损失，CLR ，JVC本来就是有幸能损失，你一点都不损？连Golang都没达到这个要求。

[jianghupt]

你搞 Java遵循Java标准，搞.Net 遵循C# 那一套，Golang同样如此 你说你不局限与语言，那只是不拘泥于某一个特定的语言，什么语言，都可以搞搞，并不是不遵循某个语言的那一套技术或者框架。 你要说什么玩意自己搞，那你只能自己玩，或者天方夜谭。 一个页面运行几个小时也不切换页面 上面说了，这种情况完全可以通过 JS来控制，你是在前端玩，不涉及到后端，不进行页面刷新，是完全可行的 但这并不脱离，目前 Web页面所包含的步骤以及程式流转所需要的过程。 你所谓的前端就是这个，那真的太浅显了。 现在项目大型分工，都有各自明确的责任，前端是前端后端是后端。因为会asp.net mvc 所以会前端开发，假如说你局限在windows平台下，完全是可行的。.net mvc 的 view 包含两种试图引起，aspx和 razor,这个微软都分别提供了相应的前端开发模式。 如说，你要跨平台，问题也不大。spring mvc View前端开发包含了html、JSP、excel表单、Word文档、PDF文档、JSON数据等数据，Core mvc 还不是太清楚。

[非专业开发Five]

引用 26 楼 tangyanzhi1111 的回复:

你搞 Java遵循Java标准，搞.Net 遵循C# 那一套，Golang同样如此 你说你不局限与语言，那只是不拘泥于某一个特定的语言，什么语言，都可以搞搞，并不是不遵循某个语言的那一套技术或者框架。 你要说什么玩意自己搞，那你只能自己玩，或者天方夜谭。 一个页面运行几个小时也不切换页面 上面说了，这种情况完全可以通过 JS来控制，你是在前端玩，不涉及到后端，不进行页面刷新，是完全可行的 但这并不脱离，目前 Web页面所包含的步骤以及程式流转所需要的过程。 你所谓的前端就是这个，那真的太浅显了。 现在项目大型分工，都有各自明确的责任，前端是前端后端是后端。因为会asp.net mvc 所以会前端开发，假如说你局限在windows平台下，完全是可行的。.net mvc 的 view 包含两种试图引起，aspx和 razor,这个微软都分别提供了相应的前端开发模式。 如说，你要跨平台，问题也不大。spring mvc View前端开发包含了html、JSP、excel表单、Word文档、PDF文档、JSON数据等数据，Core mvc 还不是太清楚。

睁开眼看看现在的前端技术再下定义吧，现在的单页应用是要走服务器下载js和当前页，但在这次下载之后所有的动作都是客户端js和服务端的交互了。 你如果还认为它会和服务端有页面级的数据交互可以开个getway看看，感受一下技术的变化。 这还没说webassembly这种运算都扔回客户端的技术。 有经验是好事，被经验蒙住眼就不对了。

[jianghupt]

引用 27 楼 胖叔叔写代码 的回复:

[quote=引用 26 楼 tangyanzhi1111 的回复:] 你搞 Java遵循Java标准，搞.Net 遵循C# 那一套，Golang同样如此 你说你不局限与语言，那只是不拘泥于某一个特定的语言，什么语言，都可以搞搞，并不是不遵循某个语言的那一套技术或者框架。 你要说什么玩意自己搞，那你只能自己玩，或者天方夜谭。 一个页面运行几个小时也不切换页面 上面说了，这种情况完全可以通过 JS来控制，你是在前端玩，不涉及到后端，不进行页面刷新，是完全可行的 但这并不脱离，目前 Web页面所包含的步骤以及程式流转所需要的过程。 你所谓的前端就是这个，那真的太浅显了。 现在项目大型分工，都有各自明确的责任，前端是前端后端是后端。因为会asp.net mvc 所以会前端开发，假如说你局限在windows平台下，完全是可行的。.net mvc 的 view 包含两种试图引起，aspx和 razor,这个微软都分别提供了相应的前端开发模式。 如说，你要跨平台，问题也不大。spring mvc View前端开发包含了html、JSP、excel表单、Word文档、PDF文档、JSON数据等数据，Core mvc 还不是太清楚。

睁开眼看看现在的前端技术再下定义吧，现在的单页应用是要走服务器下载js和当前页，但在这次下载之后所有的动作都是客户端js和服务端的交互了。 你如果还认为它会和服务端有页面级的数据交互可以开个getway看看，感受一下技术的变化。 这还没说webassembly这种运算都扔回客户端的技术。 有经验是好事，被经验蒙住眼就不对了。[/quote] -------------------- 我有说过现在前端单页面不是走服务器下载JS和当前页吗？ 你脑子是不是被驴踢了？ 前端目前这种方式并没有脱离传统模式，你下载只是一种技术或者手段，你懂不了？

[紫魂一号]

做微信公众号的时候，我就是用的api + html5 + vue 。。路由用好了，想怎么来都行啊。。V 其实就是渲染的过程。。不影响效率的

[有小猪佩奇]

请认真看楼主问的问题：
(1)总觉得asp.net mvc 请求一个页面，由ACTION返回，服务器总会有不少“负担”，需解释这页面再送给访问前端。
这说明是mvc+action，假设后缀为cshtml，也既mvc+cshtml文件
(2)想在MVC中，前端全用html文件（相当web服务器），请求的是HTML文件（js)，通过JAAX 请求MVC或API得到数据。
这说明是webapi+html文件或mvc+html文件。

什么是webapi？只要知道这一点就好了：webapi是mvc的一部分。

综上所述，楼主问的问题是使用mvc+cshtml和webapi+html的优缺点

[有小猪佩奇]

看完大神们的讨论，我给楼主总结一下：mvc+action生成的页面有缓存，mvc加html没有缓存

[橘子皮...]

发现在哪个板块都有你啊。。。 看了半天，就总结一下，如果现在学web开发，不进企业的那种，纯自己接外包，开发速度快，简洁，要学哪几种技术？！ 我刚看完flask,感觉不怎么感兴趣。前后端东西太多，高手给总结一下吧

[以专业开发人员为伍]

引用 30 楼 rongguoxu 的回复:

看完大神们的讨论，我给楼主总结一下：mvc+action生成的页面有缓存，mvc加html没有缓存

楼主说的前端是指根本不使用 asp.net mvc 的所谓页面表现层来处理交互操作的前端，也就是web 前端 js 代码处理交互——与桌面c/s程序完全一致——的前端。 而你这里还是满脑子只知道服务器端什么 mvc 编程。

[以专业开发人员为伍]

应用程序就是 html+js，而它运行时访问（通过 ajax 等机制）纯粹的数据服务，重点在于不用 asp.net mvc 提供的与 View 相关的任何页面绑定机制，跟什么“没有缓存、有缓存”有什么关系？

[有小猪佩奇]

引用 37 楼 以专业开发人员为伍 的回复:

lz 所说的“或mvc做后台返回数据”的所谓 Action 其实也就相当于 webform 的 Page对象但是不干正事儿（不输出页面）而是 Response.Write+Response.End 一样，就是对页面原本的复杂机制进行阉割。但是总之，lz 知道他自己并没有用 MVC 设计模式，所以才有此问。

我看新建API项目是在Asp.net MVC下创建，误成为MVC模式了，他们的一个是继承Controller，一个是继承ApiController，是我搞错了。 那楼主问的问题 换句话说：假设都是使用MVC(使用 Razor视图引擎)， （1）Action 返回一个非空的View，服务器端渲染数据； （2）Action返回一个空的View，客户端再使用ajax去请求数据，在客户端渲染数据； 那问题就变成了讨论【服务器端渲染数据】与【客户端渲染数据】。 服务器端渲染数据，安全性高，数据库量大的时候，影响效率， 客户端渲染数据，安全性不高，导致请求次数变多。 在一个项目中，什么时候使用服务器端渲染，什么时候使用客服端渲染，得看项目需求、数据量等等，所以应该是（1）（2）结合，而不是单纯的（1）或（2），

[以专业开发人员为伍]

引用 33 楼 rongguoxu 的回复:

什么是webapi？只要知道这一点就好了：webapi是mvc的一部分。

你认为 asp.net 中假设选择使用 webform 或者“空项目”或者“单页面项目”之类的项目类型，就不支持 webapi 了？

[以专业开发人员为伍]

mvc 就是基于 View+Model+Controller 的编程模式的工程方法，其它的都在 asp.net 中提供的功能的就不要乱张冠李戴说成是 MVC 模式。

[以专业开发人员为伍]

lz 所说的“或mvc做后台返回数据”的所谓 Action 其实也就相当于 webform 的 Page对象但是不干正事儿（不输出页面）而是 Response.Write+Response.End 一样，就是对页面原本的复杂机制进行阉割。但是总之，lz 知道他自己并没有用 MVC 设计模式，所以才有此问。

[YooK]

不考虑seo，按现在的硬件，完全可以做富客户端应用，如果是放在以前的电脑ie浏览器运行富客户端，执行大量的js估计够呛。

按SEO的角度看。富客户端的原理是先拉取脚本+HTML（可能也是脚本），首次打开会很慢，但会被缓存下来，之后与服务器交互只是拉取数据或更新脚本，相比传统的模式，它是将解析出HTML的运算摊给了用户的浏览器，但这个过程并没有任何标准，各种框架五花八门，搜索引擎爬虫无法直接分析出网站的内容，因为爬虫只认得html，而且是根据a标签href来探索新的页面，不是通过各种事件。而传统的模式是每请求页面都会拉取HTML+脚本，数据内容是直接被置入HTML里，爬虫可以直接抓到网站得html丢给搜索引擎去处理。

如果不考虑SEO，比如像内部管理系统和内置浏览器app应用，特别适合做成单页富客户端应用。

[YooK]

有人说现在用富客户端也能实现SEO，但实际上，跟现在的ajax局部刷新做SEO优化是一样的道理，后端要做数据植入到HTML的工作（这是给爬虫看的），前端也要做数据植入到HTML的工作（这是给浏览器看的），富客户端本来就该和服务端独立开来，这么一搞，又搅和在一起了。

[by_封爱]

哇塞 这个帖子讨论的好厉害 我要观战 不过我给楼主的回答就是html(argular,vue)+webapi .. 不需要什么mvc razor view 统统都不要.... 只保留接口 返回json 就够了...其他啥也不用