【问题标题】:ASP.NET Web Api vs Node.jsASP.NET Web Api 与 Node.js
【发布时间】:2014-03-17 16:05:23
【问题描述】:

我最近开始将我工作的 Web 平台连接到其他主要用 C# 编写的相当复杂的系统。 我的大部分经验是使用 PHP 和 JavaScript 进行 Web 开发 而且我也有一些在 WCF 中编写 Web 服务的经验。

遗憾的是,我在为我的 PHP Web 平台编写 WCF 服务时遇到了许多困难,开发缓慢,配置非常(非常)复杂,以便在 JSON 中做出良好响应并以 RESTful 方式工作等等。

我自然而然地开始研究其他技术,其中一项特别吸引了我的注意 Node.js,它可能对我来说是完美的,因为我在 JavaScript 方面有相当多的经验,这样我就不再需要我的 windows 服务器了。 我的另一个选择当然是继续用 C# 编写服务,但改用 ASP.NET Web API。 切换可能比从 WCF 到 Node.js 容易得多。

对此事有什么想法或建议吗? 有没有人有在 Node.js 中编写 Web 服务的经验并且可以为我指明一个好的教程的方向?还是我走得太远了,我根本不应该将 Node.js 用于 Web 服务?

【问题讨论】:

    标签: c# javascript node.js web-services wcf


    【解决方案1】:

    我最近才开始研究 express.js。让我告诉你,它不适合胆小的人。 “如果你已经熟悉 JS,那就成功了一半”的整个心态。真的不能离真相更远了。 IE。如果你是像我这样的铁杆 devops 人。

    我的所有 asp.net 应用程序构建、测试和覆盖率报告、部署、配置管理和代码质量分析都有一个统一的构建过程,所有这些都设置和自动化。我花了 5 分钟围绕一个新项目设置构建过程,并对其进行测试、分析、分阶段并将其运送到生产环境。 (世界上所有的开发人员都应该如此。但是,嘿,我在开玩笑。)然后是监控、日志记录、性能分析和分析。同样,所有这些都很好地统一、协调和集中管理。

    我并不是说 node.js/express.js 没有这些,但您必须开发/学习一套全新的服务和平台才能运行 node.js。

    敲出一堆代码是一回事。在外国技术上运行生产系统完全是另一回事。

    除非你在找麻烦 咳咳 我的意思是,挑战 :D,坚持使用 WebAPI。 WebDeploy 是天赐良机。

    顺便说一句。将 BasicHttpBinding 与您的 WCF 端点一起使用,并让 PHP 从 WSDL 生成客户端类。是的。肥皂是你的答案,而不是“更容易使用的休息”。像https://code.google.com/p/php-wsdl-creator/ 这样的东西。从 WCF 端点归档 WSDL 还允许您精确跟踪服务签名和格式更改的精确度。它确保类型安全,并为您处理 ser/de。如果我不必处理它,我不太在乎消息看起来有多丑陋。是的,我以前用 PHP 和 python 做过。完美运行。

    【讨论】:

    • 我同意这里所说的大部分内容,除了你所说的 SOAP 是答案的那一点。最好在 .NET Web API 中编写适当的 REST API,忘记 SOAP,除非您特别需要它来支持已经设计为使用 SOAP 的遗留应用程序
    • @Marty 你显然不使用 WSDL/代码生成/类型安全。私有 SOA 环境中的“REST API”没有什么合适的。您可以随心所欲地争论“人类可读性”。当我有数百个服务端点时,我想要的是通过 wsdl 的校验和来系统地查明变化。
    • 我认为问题是大多数人认为 JS 是一种相对简单的语言,因为在大多数情况下,它们的使用范围是让他们的网页跳舞(通常是在 jQuery 的帮助下)。切换到 Node 需要的不仅仅是这些,您需要以最纯粹的方式拥抱 JS(例如单线程、回调、作用域等)并严格控制您的开发——这既是一种思维方式的改变,也是一种技术的改变。
    • 如果您来自非 ASP.NET 背景(OP 似乎是),那么您关于必须学习新服务和工具的观点也是一样的,但是,一旦您设置了它曾经就像骑自行车一样。
    • @James 是的,我也错过了。范式完全不同。我也来自 ASP.Net,范围界定/回调需要一些习惯。我还在学习最佳实践的过程中。即使我可以编写应用程序和东西,也不意味着它是“正确的”。
    【解决方案2】:

    在 .net 开发 10 年后,我想将 Nodejs 用于中型应用程序。我只是分享我的经验。

    Windows 足迹

    如今,大多数新应用都部署在云中。对于 Asp.net,我们需要 windows,虽然它可以在使用 mono 的 Linux 上运行,但我对性能没有足够的信心。仅 Windows 服务器就需要超过 750mb 的内存,我想将我的应用程序部署在 1 GB 内存服务器上以降低成本。所以我想要微型操作系统。 Linux 已经证明了这一点。在这种情况下,Linux 获胜,因此节点 js。 不过我相信 Windows Nano Server 可以在不久的将来解决这个问题。 现在 .Net(核心)在 linux 上运行

    .Net 核心

    现在 .net 核心是下一个 Node JS。它为 C# 在 Linux 和 Mac 上运行打开了大门。 Unity,Xmarin 也允许创建移动应用程序和游戏。我们现在可以创建可以在 .net core、framework、xmarin 和 Unity 上运行的 .net 标准库。

    C# 开发人员的最佳时机。

    更快的编码

    我可以很好地使用 C# 和 js 编写代码。所以这对我来说不是问题......

    代码清晰

    这是一个重要的领域。当代码库增长时,JavaScript 中的一切都会变得复杂。一个人的 javascript 可能无法被另一个人阅读。许多 .net 项目具有庞大的代码库,但它易于阅读和调试。一个普通的熟练团队可以更好地管理 C# 代码。对于node js,团队必须精通JS。普通程序员可能无法正确阅读 JavaScript。

    简单

    nodeJS 非常简单,没有 dll,没有 GAC,没有类。这是很小的,非常小的代码。但是“代码清晰”对我来说比我写的行数更重要。对我来说,简单意味着易于阅读,而不是更快地编写代码。随着代码库的增长,我觉得 C# 比 JS 更简单。

    性能

    这是有争议的。我觉得我可以使用这两种技术编写性能良好的应用程序。

    开源库

    Nodejs 在这里获胜。太多的包裹,就像你早餐的种类很多。我很难选择我想要的。我花了一周时间研究 NodeJS 的 ORM 库,环顾 Sequlizer、Sails、Knex,它们都很棒。但是有些人将他们的应用程序从一个框架完全重新编码到另一个框架。这清楚地表明每个框架都缺少一些东西。这在.net 世界中从未发生在我身上。我对 Dapper 和 Service stack ORM lite 感到满意。

    但是我们在 node js 中有更多的选择,所以如果我们选择得当,一切都会好起来的。 罢工>

    码头工人

    Docker 很酷。谁会说“我不要”?这是我想要的窗户的主要内容。我听说微软已经在做一些事情了。我们必须拭目以待……

    平台可移植性

    Node js 几乎可以在任何操作系统上运行,那又如何呢?我将使用一种操作系统。 AWS 提供了很少的 linux 变体。对我来说,我的应用程序需要什么操作系统并不重要,我担心的是它的成本是多少。在这种情况下,云提供商对 Windows 和 Linux 的定价几乎相同。我喜欢 linux 的唯一原因是它占用的空间非常小。窗户不是。正如我提到的,Windows Nano 将解决这个问题。所以我可以在 Windows 服务器上运行我的应用程序。

    现在 .Net 核心在 linux 上运行,所以在 docker 上运行。

    最后我决定使用 C# 和 web api。主要原因是我现有的经验。 不过,我会在下一个应用程序中使用 node js。

    不再回头。将继续在服务器端使用 C#,并在客户端使用 React JS。

    【讨论】:

    • 仅供参考,Windows Server 2016 具有 nano 服务器,它使用的资源比完整的 Windows Server 少约 90%,还具有容器(包括 Docker)等。当然 .NET 核心在 Linux 上本机运行(不是在单声道下),所以你的大部分论点虽然在 6 个月前是正确的,今天在某种程度上是正确的,但几个月后就不会了。不过,许可成本仍然是一个问题。
    【解决方案3】:

    这两个平台各有利弊,最终两者都能胜任。

    但是,对于我来说,Node.js 两者都使用了,因为它的简单性、开发/部署速度和开箱即用的性能会胜出——如果它不是开箱即用的,很可能有package for it

    Node 已经存在了几年,然而,它直到最近才开始变得更加流行 - 以至于微软已经大大改进了 tooling support in VS

    【讨论】:

    • 交换机怎么样?在切换到 Node.js 时,我能在多大程度上依赖于我非常了解常规 JS 的事实?它们有何不同?
    • @itaywss 如果您已经熟悉 JS,那就成功了一半。但是,与任何框架一样,您需要在此过程中学习一些概念/最佳实践。对我来说,我发现过渡非常轻松。
    【解决方案4】:

    对跨平台可移植性的需求如何? 如果需要同时部署在 Windows 和 Linux 服务器上的 Web api/REST 服务怎么办?

    WCF - 我不认为它可以进入 Linux(还)(mongo??) WebAPI - 不能去 Linux(我想??) NodeJS - 可用的跨平台运行时。代码一次部署在任何地方。 xyz - 我们还有什么可以提供所有这些?

    至少正因为如此,我会建议 NodeJS 的操作

    【讨论】:

    • 你想错了。 .NET 核心具有在 Linux 和 Mac 上本机运行的 WebApi(也不使用 Mono)。 WCF,是的,它不是可移植的……但可能很快。尽管如此,WebApi 还是非常有能力的。
    猜你喜欢
    • 2012-03-14
    • 1970-01-01
    • 1970-01-01
    • 2013-10-26
    • 1970-01-01
    • 2012-03-10
    • 2012-05-30
    • 2021-10-12
    相关资源
    最近更新 更多