1
judasnow 2013-09-02 15:24:44 +08:00 1
我今年4,5月份的时候 在一个遗留系统上(原本只是一个普通的网站,也是.net)实现配套 移动app(html5 app)的时候就使用的这种架构,原因和你的差不多。
PS:具体我是这样做的:先在原先的 .net 系统上实现所需要的 web api ,再用 nodejs 调用之,前端就是一个打包的 html 加一些脚本。目前工作良好。:-) |
2
qdwang OP 还有一个好处是,开发人员分成了,算法人员和前端,本质上不需要后端这个职位了。
招聘的时候多招一些前端,就能满足大部分开发要求,灵活性也比较高,可以随时调度用于需要的模块部分。 |
3
yushiro 2013-09-02 15:25:27 +08:00
我的建议, 在没有一定量的nodejs小项目试水,获取一些开发经验之前, 不要轻易把大项目迁移上去。
前几天刚用node.js+mongodb+express做了一个爬虫,然后用瀑布流方式看爬来的照片。开发过程中,觉得各种不满意, 虽然最终是达到了初始的开发目的, 但是有不少不确定的地方,比如是否有内存泄露等。 |
4
qdwang OP @judasnow 谢谢有实际的例子,有一个需要考虑的问题是,这样做在效率上是否降低了。
我做过一个测试,就是用node包一层来反向代理.net,用的就是纯粹的http请求,效率下降了大概20%差不多。 是否让.net变成一个类似数据库的连接池,让node与.net保持长连接,这样会效率比较高一点? |
5
qdwang OP @yushiro 各种不满意,具体是指哪些呢?是用js开发不顺手,还是碰到一些技术上的问题,费了一番时间才得以解决?如果是的话,是什么技术问题呢?
内存泄露这样的不确定性问题,无论用哪个平台来开发都没办法避免,也的确是你说的,熟悉程度的问题,我会考虑的,谢谢。 |
6
judasnow 2013-09-02 15:45:56 +08:00
@qdwang 你说的“连接池”我也考虑过,我开始想的是用一个 websocket 连接,或者自己实现一个 rpc 但是我后来发现加上缓存之后(思路和你一样,只是写的时候访问 .net 的 api )性能还是可以接受的 暂时就没有深入实现了。:-)
|
7
judasnow 2013-09-02 15:47:54 +08:00
@yushiro 我也想知道您不满意的地方,我觉得只要习惯了异步之后,node 做 web service 还是很不错的。:-)
|
8
yushiro 2013-09-02 15:49:05 +08:00
@qdwang 一个是开发方式的改变, nodejs里面基本都是用callback的, 比如检查数据库中某ID是否存在, 然后走不同的逻辑, 在C#里面是同步的写法,nodejs里面就要用callback, 而且还要传后续需要的参数。
如果遇到循环调用callback, 并且需要传入不同的callback参数, 那又要牵扯到闭包。 如果你对js非常熟悉, 平时天天写原生JS代码的话,那这些问题几乎都可以忽略不计。 |
10
qdwang OP @judasnow 恩恩,看来我们想法差不多哈哈。 顺便想起来还有个好处,好多代码都可以共用,特别是一些helper代码。
|
11
qdwang OP |
12
jjx 2013-09-02 16:26:54 +08:00
1. 多线程vs 多进程
2. 同步 vs 异步 3. callback和内存占用。其实闭包的一些问题c#也有, 从orm为主到sql 为主的转变 4. 第三方包对windows支援程度 5. 怎样分发? iisnode,iis 转发? 等等 |
14
icyflash 2013-09-02 16:34:02 +08:00
|
17
qdwang OP @jjx 是的,就是有这么些问题才发帖子,不过当.net去除web服务后,本质上就是一个service了,和数据库捆绑在一起,形成一个“功能增强型数据库”。
|
18
qdwang OP @min 除了有上面jjx说的这些问题,node的另一个优势主要是,很多代码段,前后端可以共用。
比如验证,你不用先用c#写一遍,再js写一遍。架构设计好的话,非常省事。 又比如,模板生成,前后端几乎可以是一样的代码。这样在检测浏览器版本比较现代的时候,可以让浏览器来拼接模板,浏览器性能比较差的情况(比如ie67,或手机端),可以让node来拼接,而这一切不用写第二遍模板代码,却减少了服务器模板生成开支。 |
19
aaronlam 2020-12-17 17:12:06 +08:00
不知道后面这个系统运行的怎么样,我也考虑想集成 Node.js 到现有 .NET 的项目里,想了解一下,感谢!
|