ASP.NET 开发人士不必担心 Node 的五晋中由

哦别误会……我确实很喜爱
Node,而且我以为它提出的定义和方式将在很长一段时间内,对服务端 Web
编程爆发深切的熏陶。即便随着时间的推迟 Node
过气了,大家必将可以从下一个牛逼玩意身上或多或少的觉获得它的熏陶(不管好的和/或坏的)。而在这里面,大家中诸三人都会挑选它,幸福的在一块儿,生产。

  但是条条大路通亚特兰大,即使现在 Node
可能是”当红炸子鸡”,可是那不意味着在Web
服务器上没它丰盛。每一日都有不足为奇的实际上可行的出品交货,用这个巨无聊的老框架,比如说
ASP.NET, Java EE, Rails,
PHP(!)还有数不清的种种。行吗,甚至还有些疯嘿用 COBOL 搭起了 HTTP 服务!
COBOL 的 MVC … diao炸了。我给320个赞(不过千万别让我去干那事)。

  对于在那么些行当呆了近二十年有点与世无争的自己的话(摊手),好处就是… Node
指出了一个比较新的诙谐的章程来缓解这个相比老的世俗的题材。这不是降级Node。只是说,它不是唯一,后天不是明日不是后日也不会是。

  综上……若是你是个 ASP.NET 程序员然后辞了职找 Node
的干活,来啊!给自己发 email 或者 tweet,让自身清楚你能干啥
(要么干脆直接发简历……大家有在招聘哦!)。不过你若是还很迷茫,纠结于那多少个 Node-fanboy-love 的不予言论的话……继续读下来。

  1. Node最好的效劳(异步I/O)在.NET中早已存在了

  对Node最大的实证之一:Node通过采取异步非阻塞模型来处理这几个神秘的长日子运作的I/O操作。那意味着大部分在您web应用的劳动器端运行的工作(数据库查询、外部请求web
service和其它的互联网资源、访问文件等等)不会在你处理请求的主线程中发生,可以放心的延续处理其余对本站的HTTP请求。出于这一个目的,Node会维护一个线程池,那些工作将被更加调度给一个可用的线程。你可以定义一个回调函数,当其中一个亟需长日子运作的操作落成并赶回时,Node将为你调用这一个函数。那里有一个用到mongoose.js
API来询问MongoDB的事例。注意回调函数的参数以及调用‘findOne’时缺少重返值分配。

var query = Kitten.where({ color: 'white' });
// findOne()唯一的参数是一个当findOne()执行完成后被调用的函数
// 回调函数中包括错误处理以及查询结果(可以为null)的处理
query.findOne(function (err, kitten) {
  if (err) return handleError(err);
  if (kitten) {
    console.log(kitten);
  }
});

  那类“一而再传递”的编程风格有些时候对缺少经验的人来说很难把握,更加是当你的代码嵌套了千千万万层的时候。 但对于咱们熟谙的逐一风格(同步)来说仍旧有很大优势的:它为您的施行框架提供了一个自然点来做任何业务,而不是(在这一个例子里)等待query.findOne()重回 。对Node来说,总有一些其余东西在处理发来的请求。确实,Node最初的规划目的就是因为典型web服务器端的生产瓶颈就是等待I/O的姣好。Node的设计正是基于对那或多或少的考察,提供了累累属性的优势和扩展能力。

  那里是对于Node的高等级设计的描述:

  所以倘使你正在用Node,那很棒。不过有趣的是您在前日的ASP.NET中也足以使用同一的方式!可能过四人耳熟能详最初由C#5.0引入的async和await关键字。在.NET的web应用中动用它们再协作其余赞助框架比如ASP.NET,Entity
Framework等同样能够取得像Node一样的非阻塞执行作风。

  那里有一个简短的ASP.NET MVC控制器向Entity
Framework举行询问的兑现(这些格局换成Web API同样有效):

private DataContext db = new DataContext();
// GET: /Employee/
public async Task<ActionResult> Index()
{
    return View(await db.Employees.ToListAsync());
}
// GET: /Employee/Details/5
public async Task<ActionResult> Details(int? id)
{
    if (id == null)
    {
        return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
    }
    Employee employee = await db.Employees.FindAsync(id);
    if (employee == null)
    {
        return HttpNotFound();
    }
    return View(employee);
}

  有没有觉察各种方法是哪些行使async/await来回到Task<ActionResult>而不是ActionResult?那些方式在语义上确保了和Node同样的总是实施作风。await关键字标明了实施暂停的任务(并且当前线程可以先去处理其余请求),此时EF查询在ASP.NET进度外执行。当EF查询再次回到时,另一个线程用于立刻恢复生机位于’await’前面代码的实施。在ASP.NET中暂停/复苏给了我们就如Node中回调函数般的语义。落成纵然不一样,但基本原理是同等的,宝贵的劳动器端资源不可能浪费在等候昂贵I/O操作的完毕。 

  一个警戒:Node的拥护者会告诉你Node的优势在于它的布署指引你平昔进去“成功的坑”。异步是Node的默许格局,那对于Node来说万分简单,而同时您也得以在像ASP.NET那样的框架中利用异步,许多.NET开发者不这么觉得,但那活脱脱是正确的。 尽管Node应用和ASP.NET应用比起来也许会越加“异步”,但不可能驾驭成自己持有更好的吞吐量或者更好的扩张性。应用的扩大性并不在于你利用的框架,而介于你的应用本身是还是不是有不错的扩张性。若是您现在在做APS.NET,在您以为“ASP.NET贫乏扩大性”从前,花一些小时来读书并行使异步模型 。

  2. Node简化的应用模型同样在.NET中可用

  另一个Node带来的裨益是它简化的编程模型以及自主的步骤,你可以了然并精选一些更有力、更复杂的功效并将其引入。要创设一个“真正”的选拔,Node须要控制比ASP.NET更少的定义,那实则并不一定正确,但它确实给人那种感觉。那是不合理的掌握,但众多Node的初学者认为那是正确的。 

  与之比较,ASP.NET
MVC必要一密密麻麻相关的定义:HttpApplication、global.asax、web.config、模型、视图、控制器、路由、行为、束等等。作为一名有经验的ASP.NET开发者,我们觉得理所当然 。但想象一下19岁的人准备下手做web开发,给他挑选到底是进入奇特的global.asax和web.config依旧简单地搜索几行Javascript,Node会受到赏识并不意外。每一代人都会无形中地带着自豪进行开挖:“后日大家用一个马拉的犁和一个干草叉,以及一些进取心,架设了HTTP服务,大家欣赏它!” 并且每一代人都有此外一代的青少年紧随其后,转着它们的眼眸然后向发展,使用新的工具和技能。 

  额…不过再四次大家看到ASP.NET学到了有些新招数和进化。在近几年,微软致力于对.NET开发者社区定义的OWIN(.NET的绽开Web接口)规范的范围。 它的焦点境维是从服务器端的根底设备对.NET的web应用解耦,为.NET的web桟(主机,服务器,中间件和使用)定义一个标准的抽象层,同时也定义了相邻层之间交互的接口,那进步了多少个web主机间的可移植性。它同时也视作Katana项目的基础,Katana项目是微软对OWIN的兑现,意在通过传统的ASP.NET管道、HttpListener、IIS、主机以及此外更加多东西来处理HTTP请求。

  OWIN和Katana借鉴了Node和其他过多轻量级框架,所以编程模型简单亲密。记得在Node里”hello
world”有多不难吗?看看Katana:

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Run(context =>
      {
         context.Response.ContentType = "text/plain";
         return context.Response.WriteAsync("Hello World!");
      });
   }
}

  很简单啊!为其他给定的终结点简单定义行为(上边的代码应用的简易行为为那一个动用的有所终结点所共用)。注意代码默许是异步的,如同Node一样。什么人说老狗无法学新招数!

  明确地讲,上面的代码在其余Katana主机上都得以运行:IIS,OWIN.exe(一个微软提供的控制台host,类似于node.exe),或是你自定义的host已毕。可以在多台主机和服务器端运行同样的代码是Katana分外有效的职能,而Node没有提供。

  等等,还有!Katana有一个在常用IIS+ASP.NET服务器基础设备中的弱点,它借助于System.Web,它不但囊括ASP.NET管道中的类型(HttpApplication,HttpContext,IHttpModule,IHttpHandler等),它还包罗部分Web
Forms的编程模型(pages,contorls,view
state等)。你实在想把这一个都带到你现代的轻量级Katana应用程序域中?是的,ASP.NET团队不认为你会使用其中任何一个。 

  所以他们成立了Helios项目。Helios是一个雏形项目,意在具体化使用IIS(利用IIS的安全性、缓存、进度生命周期管理等)host的OWIN应用不须要将System.Web拖入你的采用程序域。 Helios是一个pre-alpha版本,所以大家须要小心比较。不过,相比较ASP.NET
host的应用,Helios确实表明方可鲜明回落请求钱的内存消耗,它预示了.NET的web桟在以后将尤为简洁,更具增加性。那对于ASP.NET开发者而言是好事,你可将来天下手琢磨OWIN和Katana。最后,让ASP.NET团队知道您要求一个法定完整接济、类似于Helios的使用桟!

  3. Node的”到处都是Javascript”很棒!除非它不是 

  Node的其中一个论证是在您所有应用桟中您可以只使用Javascript。这实在有过多优势。 

  除非你所在的团体里不曾全职的JavaScript程序员。除非您愿意花钱去招聘一些当下市面上高须求的科学技术人才。或者唯有您愿意用JavaScript重写你的任何应用程序(或者您正从零开始……在那种场合下,你或许没有重写的题材,但你一定有“我到哪能够找到全职JavaScript开发者”这么些难点)。

  对一个从更传统的面向对象语言如C#人来说,了然(或通晓)JavaScript是件难事。原型继承很是强劲,但也很不难绕住你。变量的范围“规则”,嗯,也很有趣。强制类型转换,有时须求,貌似很随便。“typeof
NaN ===
‘number’”。相信我,还会蒙受越来越多。没有怎么是不可逾越的,JavaScript的生产力是不单此而已。像TypeScript那类的东西很有赞助,更加对从C#更换来JS。只是不要期望一夜之间就能不负众望。

  那是原因的一片段,对所有时兴的技能,Node对集团级来说依然是新的。当然,一些喜爱尝鲜的人已接纳多年(公司中也有人员在品味前卫的使用框架)。但在短时间内,若是您在Bigcorp.com上找寻能引入Node的美貌,你可能要求交给一些使劲。那并不意味着你可以不在乎Node……但要把握实际期望值。

  其它,注意到客户端JavaScript开发与劳动器端开发相同却又完全差异很重点。语言的歧异并不那么大(确实不大),但概念和格局只有为数不多的重叠。你须要的人不仅要了然JavaScript,也要知道互连网延迟、异步、服务器的平凉、规模缩放、云测试和布置以及高速的多寡访问,等等。固然是一个美妙的客户端js开发者也未必完全知晓那几个。反过来,若是您的商店刚先导做.NET开发,我敢打赌你团队中也有多少人知道那个事物。他们也许不打听Node (近年来还不),但她俩仍有您可以运用的知识。

  到此处,大家看来了单向难点。不管JavaScript和Node近日多火。首要的是它们是还是不是适用于你的具体情形。是的,想有些前途的技艺方向和“人才市场”走向是很重点的……但你对你控制的东西有多大的信心?大家可以接受部分作育来狐疑后天……但就是他俩所做的,推测而已。一个簇新的区域……C#兴许不“酷”了,但它仍不会疾速烟消云散。

  越多的在上面。所以,要是你欢欣Node那为它而欢娱吧,精晓下它看看是还是不是相符你和你的公司。但您要率先注意于前些天的须要,适当少关怀你将使用的下一个闪光的新东西。当你准备好时它就会冒出闪光。

  4.什么样你的ASP.NET应用程序规模不大但影响迟缓,也许那几个标题在于你的筹划

  那种差异将堵住你选取Node重写你的Web应用以修复你眼前在ASP.NET的达成中所存在难点。用Node重写不会有明确协理,很可能没有其他援救。

  那如同在Ye
Ole软件协会中的穆哈咖啡参与印度茶必然会造成溢出同样。因而转向Node不会简单的解决您的标题…..那么些标题标发源在于你,而不是微软。

  询问你自己(坦诚的)适合下列描述的那种:

  1.您和你的公司有着远见,杰出的软件工程师将选用时间尽量识别出ASP.NET中最佳的软件工程执行并将她们选用于您的连串。你的规划是 SOLID。你可以对何模块进行单元测试。你通晓您的的代码测试覆盖标准,并且你知道他干吗不是100%。你冷静的辨析 Entity
Framework,、NHibernate,原生ADO.NET和百万级
micro-ORMs 框架的优缺点并且按照你项目标限制做出合理的选项。你通过长日子的困顿思考决定你怎么着聚合于你客户端和劳动器端应用程序的事务逻辑,考虑接下去的技艺、工具、生产力和性质等等如何影响你的决策。你与协作伙伴劳累的效仿现实世界的用例和内容,甚至在品种初期设置品质层级和加载测试场景,所以你在当时就持有关于质量和规模的图样。你可以多多次自由的写照你的行使和数目访问权限,你也可以修改他们照旧去掉那几个没有此外区其余叠加功用。管理人员了解这一个事情须要时间,不过你要求交出高质量的代码。

  2.
您和您的团协会目光短浅,非理性的“开发者”干着没有能力胜任的办事而且不顾一切保住工作。
依照定义,你一贯没有读过关于ASP.NET
最佳实践的书或者作品(假设你正在读那篇小说,你可以在Stack
Overflow上经过链接找到最佳实践的素材,搜索GDD或者谷歌-driven
development)。 你的安顿规范是,“solid”。
曾在您团队里待过的开发者写了一部分单元测试用例,当一些代码改变时,你把它们诠释了,这么些用例永远不会再编译(即使你的项目高管在给CTO的代码质量周报中依然引用这个用例)。
有四回,你从换过一遍工作的同事那里听说实体框架“很烂”,NHibernate“太复杂”,由此你编写自己的DAL拼装内存中的SQL语句(通过请求…没有缓存),并有限协理你的动态数据库字段(ExtraColumn1,ExtraColumn2,…ExtraColumn25)都读取到格外地点,在一个记录的底蕴上(或者…你从另一个同事那里听说实体框架EF“很棒”,由此所有服务器端架构你使用EF对象图的操作深层次结构,EF对象图映射由一个从未见过7张表关联的“数据库架构师”设计的出色第五范式的数据库)。你不领悟分析器是何许事物。
“SQL执行安插”对您而言,听起来像是要进牢房的工作。你“测试”系统好多少个月了,却绝非尝试并发用户请求,你的可扩充性就是“买越多的硬件”。
等等。

  3. 在乎第 1 和第 2 种状态之间.

  老实说, 大家中间很多集体既不属于第 1 种也不属于第 2 种, 而是介于 1
和 2 之间. 那很正常,那芸芸众生没有周详无缺的花色, 也绝非两全无缺的团协会.
所以, 借使你比较匡助于地方提到的第 1 中状态, 而且在坚实 ASP.NET
的习性和扩充性方面, 你曾经竭尽所能, 做了你能做的, 结果仍旧不如愿,
那么, 也许是时候改用其余框架了.

  唯有无能的美貌会把团结的过错推给工具. 自己的次第有难题怨 ASP.NET
那就是现代版的在编译器中找 bug. 拉不出屎, 别怪茅坑…
难点或者来至你的团伙. 当然, 我不是说 ASP.NET 很完美, 一点难题也尚未
(事实上, ASP.NET 本身也有很多不足). 它不过是个工具, 一个得力的工具,
一个众多的网站每日都在常规使用的工具. 其中一部分网站(甚至是多数的网站),
其复杂程度,访问量要比你的高的多. 像这么一个身经百战,
被使用多年的框架, 不可能满意你的体系用度须求的可能性, 坦白讲, 不大.

  基于对“更好”一词差别的概念,以上几点并不是说Node比ASP.NET
更好或更糟。 它是说只要你布署由ASP.NET
转向Node,那很好,可是毫无批评ASP.NET
在性质和可伸张性方面的难题。在“自由地报名愈多可增添性”方面,Node并不是神奇的魔法粉。
Node 只是一个好像于ASP.NET
的工具…使用方便,它的法力很好。草率地使用并且没有知晓地精晓它的利弊,就好像花了大气的大运和金钱重写Node,最后会回去原点,就是你今天所处的义务。

  我的爱人,这如同一声相当痛楚的低音号。

  5. 亲骨血,“微软正在流失!/破产!/邪恶!/无聊!/土里土气!/等等。”绝不能孕育一个科学和技术战略

  现在,正如您读到的,由于一些不理性、毫无缘由的厌烦微软,一些在铺子级软件领域工作的人正在由
ASP.NET 转向 Node。这么些人在她们的团伙之中是值得信任的领导者。
他们对买卖上可见发生很大下游影响(正面或负面)的技术决策负有义务。当您跳过她们
PPT摘要页、第一页或者第二页查看前面的情节时,站不住脚的说辞没有了,他们的说法差不离可以归咎为“我不喜欢微软,我不喜欢ASP.NET,我想做年轻人正在做的相比较酷的政工”。

  停止二〇一三年14月31日,《金融时报》(FT)全世界500强指数中微软市值名次第四。
在同一季度,微软受益创纪录地落成245亿英镑。 微软还没有败北,远非如此。
微软Azure充满活力,它为合作社不止迁移到云提供突出的定位,在这一领域,它具备竞争力,而且这一天地咱们方今只有发展到先前时期阶段。绝对于传统的Office办公软件,Office
365已改为一个有效的根据云计算的替代产品。和另国集团一如既往,微软不断地大方地投资于研发领域(那怎么会“无聊”呢?)。
微软“土里土气”吗?如若您根据商家级IT解决方案的定义而问这几个题目,你是否发现自己已经错了?

  不要误会 …
在一个大的崭新的类型始于,有广大说辞接纳使用其余产品而非微软的产品。
中期的准许费用可能难以接受,尤其比较于种种开源的软件(固然有
方法减轻那个成本)。在那一点上,至少微软部分
大旨技术的深入生存能力是不安静的。基于 Satya Nadella升职为
高管及她所有喜欢的了然发言,我们照样不亮堂他是或不是有能力使用好微软
已部分优势,并缓解微软面临的标题。

  不过,即使你已经投入巨资并精晓地创立了一个技能优势,放弃它再也开端平常是一个荒谬。
100年前Joel那样写到。以我的阅历,这一般是一个勉强上的支配,而不是一个靠边上的决定…不管商量哪一种技术。

  如若你是一个 CTO,面对遗留的 ASP.NET 代码那座大山,你觉得用
Node重写将会缓解所有的题材,你这在给你的商店、你的董事会、你的客户帮倒忙。他们给您薪酬不是为着让你在流行技术中换到换去。他们给你薪水也不是为了让您发挥对微软肥皂剧故事“本周流行哪个技术?”的厌烦。“他们给您薪金是为着贯彻商业价值

可预言的经济上的市值,并且产品要有高品质。当开端做的时候,研发技术的抉择比我们想要外人认同的采用要少的多。
在一个软件项目中,一大半可变性是以人为中央。不过当大家可以批评团结的老毛病时,事情却变得简单得多,”每个人都通晓ASP.NET 不可以形成规模“。

  让大家若是你是一个基于ASP的网络店铺,不过你稍微担心过头器重单一的供应商。你有怎么着方案能跨越“重写所有Node”?首先,你可以标识部分你的架构,它或许得益于各个开源的替代方案,用它们变更盒子中的ASP.NET。对于.NET来说,过去几年热火朝天的开源生态系统使得其尤其地优雅的严重性原因(首要原因?)。整个框架是远大的,可是你也足以设想像Massive或者
Simple.Data那样的代表方案?也许你的数量访问策略须求一个面目一新,使用NoSQL数据库MongoDB 或者 RavenDB,您的应用程序会受益?也许,你建立了一个相宜的服务层,能够动用新样式,像responsive
UI那样直接的点子。那些品种的架构更改绝非易事,他们不被认为是轻量级的,不过她们或许必要缓解具体的难题,却面临着尚未更大的预算去抛掉风险,重新开首。

  其次,考虑越来越多激进的想法,比如在Mono平台上运行,选取自己的主机操作系统。现在ASP.NET和MVC在Mono上运行得一定好。
若是你对云技术感兴趣,然而不想利用Azure,你有别的的阳台运行ASP.NET… AWS
EC2(亚马逊可扩展的云托管)虚拟机,AWS Elastic
Beanstalk (亚马逊(亚马逊)的PaaS服务),小型的云总结空间供应商如AppHarbor,还有目前发表的协助.NET的红帽OpenShift(云总括服务平台)。

  最终,在控制取舍哪位技术和平台前,确定你早已找到选用的说辞。
除了前头提到的准许开销,还有众多亟需考虑的事物。所有权的总费用并不唯有中期费用,也有利用时的开销… 其中一些开支不便于开展量化。 使用
Node举办重写,你的团社团可以准时已毕的机会费用是稍稍?ASP.NET应用开发遭遇题目时,你可以24*7通话寻求技术援救而不是无论在一个
Node开发者论坛上找寻答案,那对您而言价值是稍稍?你所处的地理区域是前者人才如
Node越多,仍旧主流技术的专家如 .NET和 Java更加多? 找到、吸引、留住美好的
Node开发者难度是多大?你是或不是准备好应对他们也许被挖走的标题?
最近您的团伙居多开发者都控制了有价值的园地标准知识 … 当您转向
Node时,你是还是不是布置继续封存这一个开发者?怎么着将专业知识转化为一门新的技艺架构?要是你布署不再雇佣他们,你规定你曾经准备好望着她们带着困难的园地知识走出公司大门?

  那里没有好坏…
它不像招聘”过时的”开发者:精晓过时的技艺、对招聘人员也远非吸引力,那是一个打响的招贤纳士策略。说句公道话,永远坚贞不屈采取ASP.NET(或任何任何一门技术)也不像是正确的选项。在你做出由ASP.NET转向Node重大的主宰从前,必须合理合法而不是不合理地考虑地方的具备因素。保持审慎,保持合理。

  希望我在小说里早已给你了有些思想的东西。
我很欣赏Node,在接下去的几年自己布置成本越来越多的时光攻读它。
不过自家也很喜欢ASP.NET… 鉴于它的功能和前程的设计。
明智的做法是对双边都维持关怀,不要过早地下决定。

  最终,对于分化的现象下抉择哪一种语言并不曾一个唯一的答案,可是可以参见一些率领性的标准。
让我们在下一篇文章中对这几个标准进行探讨。

网站地图xml地图