.NET 框架之“小马过河”

.NET框架之“小马过河”

有许多流行的 .NET 框架,大家都觉得挺“重”,认为很麻烦,重量级,不如其它“轻量级”框架,从而不愿意使用。面对形形色色的框架发愁,笔者也曾发愁。但我发现只要敢于尝试,这些框架都是“纸老虎”。就像“小马过河”一样,自己尝试一下,就会发现“原来河水既不像老牛说的那样浅,也不像松鼠说的那样深。”

项目中的代码,都在 LINQPad6 中运行并测试通过,也可以复制到  VisualStudio 中执行。

做简单的 Http 服务器很“重”

有些非常简单的 Http 服务器,我看到有些  .NET 开发居然也用  Node.js 、  Python 等语言,一问,他们会回答说“这种简单的东西,用  .NET ,太重了”。殊不知其实用  .NET 做起来,也很轻(甚至更轻):

运行效果:

可见,包括空行,仅10行代码即可完成一个简单的 HTTP 服务器。

使用 EntityFramework 很“重”

EntityFramework ,简称  EF ,现在有两个版本,  EFCore 和  EF6 ,其中  EFCore 可以同时运行在  .NETFramework 和  .NETCore 中,但  EF6 只能在  .NETFramework 中运行。本文中只测试了  EFCore 但  EF6 代码也一样简单

EntityFramework 是  .NET 下常用的数据访问框架,以代码简单、功能强大而著名。但不少人却嗤之以鼻、不以为意。询问时,回答说  EntityFramework 很“重”。

这个“重”字,我理解为它 可能 占用内存高,或者它 可能 代码极其麻烦,配置不方便(像  iBatisHibernate 那样),真的这样吗?

如图,假设我有一个 UserVoiceStatus 表:

下面,我们通过 EF 将数据取出来:

执行效果如图:

注意,如果使用 LINQPad ,事情还能更简单,只要一行代码即可,效果完全一样:  UserVoiceStatuses

使用 ASP.NET MVC 很“重”

上文说到了如何做一个简单的 Http 服务器,如果想复杂一点,初始化  ASP.NET MVC 也很简单,甚至只需要一个文件即可完成:

麻雀虽小,五脏俱全,这么简短的几千代码中,可以使用 Https 、包含了依赖注入,还能完整的路由功能,就构成了  ASP.NET MVC 的基本代码。运行效果如图: 

使用 WebSockets 很“重”

WebSockets 是个流行的  Http 双向通信技术,以前在  Node.js 中很流行(用  socket.io )。代码如下:

该代码是个 Echo 服务器,它会将客户端发过来和内容,按原因返回给客户端。然后,  .NET 也内置了  WebSockets 的客户端:可以高效地访问刚刚创建并运行的  WebSockets 服务器。

最后,客户端与服务器双向通信效果如下:

使用 SignalR 很“重”

SignalR 是  ASP.NET 推出的抽象式的  Http 协议双向通信框架。  SignalR 可以用相同的  API ,支持像长轮询、  ServerSentEvents 和  WebSocket 的技术。  SignalR 默认优先选择使用  WebSocket 以达到最高性能,如果客户端或服务器不支持,则会回退至其它稍慢的技术。

SignalR 客户端还支持几乎所有语言、所有平台。它是如此好用,几乎可以取代传统的请求/响应,成为新的  Http 开发模型。(事实上  Blazor 正在尝试这样做)

SignalR 最为令人震撼的,还是它非常简单的使用方式,而恰恰是这一点给人误会最深。它的服务端  API ,甚至比  WebSocket 还要简单清晰简单:

前文提到, SignalR 提供了所有平台的  SignalR 客户端,如  js 、  Android 等,其中当然(显然)也包括  .NET 的。  SignalR 的  .NET 客户端使用起来也非常简单:

这是一个非常简单的多人聊天室,运行效果如下:

总结

面对形形色色的框架发愁,笔者也曾发愁。但现在不了,什么框架拿过来,马上试试,也就几 秒钟的事。好用不好用,用用便知。

那么读者,你的“小马过河”的故事是怎样的呢?

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章