纠结 前后端分离 是否需要用Node.js

aspnet30 2019-03-17 04:58:01
需要开发一个PC端的库存管理系统
用Vue.js+asp.net web api开发
因为工期和人手有限,如果不考虑SEO,多个api合并等问题,不用Node.js做中间层可以吗,后续会遇到哪些问题。
Vue.js本身就有路由功能,直接在Vue中调用web api可以吗
...全文
1123 26 打赏 收藏 转发到动态 举报
写回复
用AI写文章
26 条回复
切换为时间正序
请发表友善的回复…
发表回复
Jetaime79 2020-03-07
  • 打赏
  • 举报
回复
引用 25 楼 by_封爱 的回复:
[quote=引用 24 楼 Jetaime79 的回复:] 十三楼的回复让我觉得很智障, 你不要不懂就误人子弟。
我觉得你似乎没理解人家的方式.. 人家说的本质是.. 自己使用tcp/ip做一个http服务器... 通过报文解析http协议 然后输出http的response协议 来实现自己的"iis". 而不是用什么asp.net 更不用说是iis了... 反倒是你自己..你是不是觉得你自己的思想已经达到了登峰造极境的境界,都能随便去理解别人的思路了? [/quote] 并没有 我说的不是那个人 我回复应该是#14楼 的这句话 “对啊我在给你推荐监听80端口啊,理论上来说监听80端口你将会抛弃web中很多不需要的东西,速度会更快的!” 小白一个不敢说登峰造极,你认为监听80端口 速度会比其他的快吗? 所以大神什么的我不是 我只是实质的回答而已,这本身就是网络模型的原理 并不是我的思想。我没那么牛逼,你认真看 他说理论上 理论就不是这样的。
by_封爱 2020-03-06
  • 打赏
  • 举报
回复
引用 24 楼 Jetaime79 的回复:
十三楼的回复让我觉得很智障, 你不要不懂就误人子弟。
我觉得你似乎没理解人家的方式.. 人家说的本质是.. 自己使用tcp/ip做一个http服务器... 通过报文解析http协议 然后输出http的response协议 来实现自己的"iis". 而不是用什么asp.net 更不用说是iis了... 反倒是你自己..你是不是觉得你自己的思想已经达到了登峰造极境的境界,都能随便去理解别人的思路了?
Jetaime79 2020-03-06
  • 打赏
  • 举报
回复
十三楼的回复让我觉得很智障,“对啊我在给你推荐监听80端口啊,理论上来说监听80端口你将会抛弃web中很多不需要的东西,速度会更快的!” 我想问 你真的理解端口是什么东西吗 什么叫监听80端口会抛弃web很多不需要的东西,端口是传输层的东西跟这些半毛钱关系没有,这说明你对网络不熟悉,第二是你对协议这东西不理解,没时间跟你解释OSI七层模型,数据到达了模型的传输层被赋予端口,只是规定了把数据发往主机(服务器)的哪个端口 ,只要服务器的端口范围不超过65535不被占用的情况下监听都可以接受数据,至于http协议是应用层上的东西,如果你发一个http请求过去,假设有apache监听这个端口,它会认识http,自然能有正确的响应,你如果发一个FTP的请求过去,你看看它能认识不,估计404都没有,客户端超时了,你不要不懂就误人子弟。
jimmy_lee-0609 2019-03-24
  • 打赏
  • 举报
回复
Java spring MVC, .net后端可以只选一个,你喜欢可以都用,前端页面控制可以直接Web API,或者用 vue,react, angular 。前后端通信约定用JSON。后端只管数据处理,获取,前端只管页面控制。 node.js只是一个运行环境。js 的框架开发的时候需要用到,将前端的HTML和js 打包好,可以直接放到服务器的指定路径,就可以用这些静态资源拉。 虽然node.js他有HTTP 模块,可以添加模块后处理 HTTP请求,我个人不太喜欢用。
baidu_27549073 2019-03-21
  • 打赏
  • 举报
回复
前后端分离的意思是可以前端搞前端的,后端搞后端的,自己想用什么技术就用什么技术。 分离的好处就是,你前端用js,后端不一定要用nodejs。 后端用Asp.Net,前端不一定用Asp.Net
baidu_27549073 2019-03-21
  • 打赏
  • 举报
回复
引用 21 楼 aspnet30 的回复:
我看很多文章里,介绍的node.js并不是用来写后端,而是前端人员用node.js来控制模板输出,合并接口等
这又是另外一个故事了。
aspnet30 2019-03-21
  • 打赏
  • 举报
回复
引用 20 楼 baidu_27549073 的回复:
前后端分离的意思是可以前端搞前端的,后端搞后端的,自己想用什么技术就用什么技术。
分离的好处就是,你前端用js,后端不一定要用nodejs。
后端用Asp.Net,前端不一定用Asp.Net


我看很多文章里,介绍的node.js并不是用来写后端,而是前端人员用node.js来控制模板输出,合并接口等
  • 打赏
  • 举报
回复
哦,上述代码可能应该写为
    public abstract class MyCommand<S, R> : IMyCommand
    {
        public dynamic Execute(JObject input)
        {
            return Execute(input.ToObject<S>());
        }

        public abstract R Execute(S input);
    }
才对,也就是说把原本对于 IMyCommand 的 Execute 的弱类型调用委派给新的强类型的 Execute 调用。这样以后的自定义服务类型就都从 MyCommand 继承,只写(并且只能写)强类型的 Execute 而不需要写任何弱类型的 Execute 实现了。
  • 打赏
  • 举报
回复
有关“参数强类型化”,等等控制需求,其实都在于你的 IMyCommand 的进一步细化。例如你可以定义个类似
    public abstract class MyCommand<S, R> : IMyCommand
    {
        public dynamic Execute(JObject input)
        {
            throw new NotImplementedException();
        }

        public R Execute(S input)
        {
            return (R)Execute(input);
        }
    }
这样的类型封装,就能将原来弱类型的 IMyCommand 转而封装为强类型的,从而你的真正的所有的服务都是从 MyCommand<,> 继承的而不是从弱类型 IMyCommand 继承。 诸如此类的扩展,例如你可以扩展接口,或者扩展 Attribute 定义,来实现类似于“设置服务权限”等等等等你需要自己扩展的功能。关键是说,从根源上掌握机构设计主动权。
  • 打赏
  • 举报
回复
举一个自己写 http 服务的例子:
    public interface IMyCommand
    {
        dynamic Execute(JObject input);
    }

    public class Handler1 : IHttpHandler
    {
        private static Dictionary<string, Type> Commands = new Dictionary<string, Type> {
            { "给我一支笔", typeof(给你笔) },
            { "abc", typeof(另外一个服务)} };

        public void ProcessRequest(HttpContext context)
        {
            var reader = new StreamReader(context.Request.InputStream);
            var text = reader.ReadToEnd();      //断点调试这里,可以得到客户端的所有提交的 string
            var obj = JObject.Parse(text);      //从收到的 string 转换为 Json 格式
            var commandName = (string)obj["ServiceName"];
            if (Commands.TryGetValue(commandName, out Type h))
            {
                var run = (IMyCommand)Activator.CreateInstance(h);
                var result = run.Execute(obj);
                context.Response.Write(JsonConvert.SerializeObject(result));
            }
            else
                context.Response.StatusCode = 404;
        }

        public bool IsReusable
        {
            get
            {
                return false;
            }
        }
    }
    public class 给你笔 : IMyCommand
    {
        public dynamic Execute(JObject input)
        {
            return "你要笔是" + (string)input["型号"] + "的?";
        }
    }

    public class 另外一个服务 : IMyCommand
    {
        public dynamic Execute(JObject input)
        {
            return null;
        }
    }
这里,用一个 commands 字典来把自己的凡是能解析执行 IMyCommand 接口的命令(这里写了2个例子)注册一下,然后这个 ashx 就可以自动承载所有的服务请求接入和输出工作了。这里用简洁的代码,从这个简单的demo开始,自己把控的每一个细节,你可以插入各种预定义处理,进行各种优化。一切都在自己掌控。
  • 打赏
  • 举报
回复
引用 14 楼 胖叔叔写代码 的回复:
[quote=引用 13 楼 好奇都是要学的 的回复:] [quote=引用 12 楼 胖叔叔写代码 的回复:] [quote=引用 11 楼 好奇都是要学的 的回复:] [quote=引用 8 楼 胖叔叔写代码 的回复:] [quote=引用 7 楼 好奇都是要学的 的回复:] HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
小项目是这样,你就是手写监听80端口返回数据都可以,你想象一下几千个接口,然后要修改一个每个接口都有的返回值的key名称,你ashx页面要修改多少地方?而webapi+orm等你可能只用修改一下一个model文件的一个变量名。[/quote] 就跟权限判断 肯定要写个方法 , 不可能每个接口功能里 都写权限判断, 权限有改动 , 所有接口里的权限都要改,那不改死了。 以前用c或者c++写东西的, 模块方式都是用case , 那接口更多,那他们怎么写啊[/quote] 就还是我说的,你自己爱怎么做怎么做,你监听80用socket也没什么不行[/quote] 我们讨论的不是设计, 我的意思是 ashx比web api 更快 更轻便。 所以我选择他。[/quote] 对啊我在给你推荐监听80端口啊,理论上来说监听80端口你将会抛弃web中很多不需要的东西,速度会更快的![/quote] 我感觉咱俩说都不是一个是
  • 打赏
  • 举报
回复
我平时就只是html+webapi,
感觉webapi就是你说的路由作用
  • 打赏
  • 举报
回复
引用 13 楼 好奇都是要学的 的回复:
[quote=引用 12 楼 胖叔叔写代码 的回复:] [quote=引用 11 楼 好奇都是要学的 的回复:] [quote=引用 8 楼 胖叔叔写代码 的回复:] [quote=引用 7 楼 好奇都是要学的 的回复:] HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
小项目是这样,你就是手写监听80端口返回数据都可以,你想象一下几千个接口,然后要修改一个每个接口都有的返回值的key名称,你ashx页面要修改多少地方?而webapi+orm等你可能只用修改一下一个model文件的一个变量名。[/quote] 就跟权限判断 肯定要写个方法 , 不可能每个接口功能里 都写权限判断, 权限有改动 , 所有接口里的权限都要改,那不改死了。 以前用c或者c++写东西的, 模块方式都是用case , 那接口更多,那他们怎么写啊[/quote] 就还是我说的,你自己爱怎么做怎么做,你监听80用socket也没什么不行[/quote] 我们讨论的不是设计, 我的意思是 ashx比web api 更快 更轻便。 所以我选择他。[/quote] 对啊我在给你推荐监听80端口啊,理论上来说监听80端口你将会抛弃web中很多不需要的东西,速度会更快的!
  • 打赏
  • 举报
回复
引用 12 楼 胖叔叔写代码 的回复:
[quote=引用 11 楼 好奇都是要学的 的回复:] [quote=引用 8 楼 胖叔叔写代码 的回复:] [quote=引用 7 楼 好奇都是要学的 的回复:] HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
小项目是这样,你就是手写监听80端口返回数据都可以,你想象一下几千个接口,然后要修改一个每个接口都有的返回值的key名称,你ashx页面要修改多少地方?而webapi+orm等你可能只用修改一下一个model文件的一个变量名。[/quote] 就跟权限判断 肯定要写个方法 , 不可能每个接口功能里 都写权限判断, 权限有改动 , 所有接口里的权限都要改,那不改死了。 以前用c或者c++写东西的, 模块方式都是用case , 那接口更多,那他们怎么写啊[/quote] 就还是我说的,你自己爱怎么做怎么做,你监听80用socket也没什么不行[/quote] 我们讨论的不是设计, 我的意思是 ashx比web api 更快 更轻便。 所以我选择他。
  • 打赏
  • 举报
回复
引用 11 楼 好奇都是要学的 的回复:
[quote=引用 8 楼 胖叔叔写代码 的回复:] [quote=引用 7 楼 好奇都是要学的 的回复:] HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
小项目是这样,你就是手写监听80端口返回数据都可以,你想象一下几千个接口,然后要修改一个每个接口都有的返回值的key名称,你ashx页面要修改多少地方?而webapi+orm等你可能只用修改一下一个model文件的一个变量名。[/quote] 就跟权限判断 肯定要写个方法 , 不可能每个接口功能里 都写权限判断, 权限有改动 , 所有接口里的权限都要改,那不改死了。 以前用c或者c++写东西的, 模块方式都是用case , 那接口更多,那他们怎么写啊[/quote] 就还是我说的,你自己爱怎么做怎么做,你监听80用socket也没什么不行
  • 打赏
  • 举报
回复
引用 8 楼 胖叔叔写代码 的回复:
[quote=引用 7 楼 好奇都是要学的 的回复:] HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
小项目是这样,你就是手写监听80端口返回数据都可以,你想象一下几千个接口,然后要修改一个每个接口都有的返回值的key名称,你ashx页面要修改多少地方?而webapi+orm等你可能只用修改一下一个model文件的一个变量名。[/quote] 就跟权限判断 肯定要写个方法 , 不可能每个接口功能里 都写权限判断, 权限有改动 , 所有接口里的权限都要改,那不改死了。 以前用c或者c++写东西的, 模块方式都是用case , 那接口更多,那他们怎么写啊
  • 打赏
  • 举报
回复
引用 8 楼 胖叔叔写代码 的回复:
[quote=引用 7 楼 好奇都是要学的 的回复:] HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
小项目是这样,你就是手写监听80端口返回数据都可以,你想象一下几千个接口,然后要修改一个每个接口都有的返回值的key名称,你ashx页面要修改多少地方?而webapi+orm等你可能只用修改一下一个model文件的一个变量名。[/quote] 那是前期没设置好的问题, 返回的 就是JSON 统一地方返回, 修改的时候 只要改你需要的接口就好, 功能模块化, 返回也是个模块,才不关心你返回什么。
  • 打赏
  • 举报
回复
引用 1 楼 以专业开发人员为伍 的回复:
为什么要用 Node.js?
大佬 我问下, 是不是 .net这么多 服务里 ashx 是最快, 最轻便的。 比web api 和 webservice 返回数据都快 09年 我接触的webservice 返回的是datatable 接收的时候也是datatable 是.NET 自己封装的吧。 但是很慢 11年开始用ashx 开始有个跨域名问题, 现在已经不是问题了 现在又出了web api 但是我看下了, 感觉还是.NET 封装了 一堆东西 提供了路由, 觉得没有ashx 好。 我08年开始干,到19年一直 都是哪里不会学哪里 没有系统的看过什么,基础知识很差。 我看了你很多东西 说的都是原理 受益匪浅
  • 打赏
  • 举报
回复
引用 7 楼 好奇都是要学的 的回复:
HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
小项目是这样,你就是手写监听80端口返回数据都可以,你想象一下几千个接口,然后要修改一个每个接口都有的返回值的key名称,你ashx页面要修改多少地方?而webapi+orm等你可能只用修改一下一个model文件的一个变量名。
  • 打赏
  • 举报
回复
HTML + JS +.net ASHX 我觉得足以。 我感觉 web api 不如 ASHX 如果加上 SignalR 推送都搞定了, 为什么要弄的那么麻烦。
加载更多回复(6)

62,017

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧