www.9778.com 7

.NET Core 2.0 是您的最好选择吗?

目前 .NET Core 3.0 拥有的 API 总数约为 .NET Framework API 的
80%,剩下尚未从 .NET Framework 移植到 .NET Core 的
API,微软考虑以开源的形式发布。

微软方面表示,通过.NET Core
3.0,他们现在已具备轻松移植现代workload所需的所有技术,无论是桌面应用、移动应用、控制台应用,网站还是云服务。为此,他们计划将不再把.NET
Framework上已有的技术移植到.NET Core
3.0,并考虑使用MIT协议来开源不打算移植到.NET Core 3.0的.NET
Framework代码库。

2014年11月12日的Connect
();开发者活动上宣布将.NET堆栈基于MIT协议开源,并且提供开源保证,托管在Github上。当时的版本与最终目标相距甚远,然而有一点可以肯定的是,这是一个与.NET
Framework 4.x完全不同的框架。

  • 1. NET Core 2.0
    是您的最好选择吗?

    • 1.1. Net Core 2.0
      特性

      • 1.1.1. NET
        Core平台是开源的
      • 1.1.2.
        跨平台
      • 1.1.3.
        灵活部署
      • 1.1.4.
        模块化架构
      • 1.1.5.
        命令行工具
      • 1.1.6.
        云支持
    • 1.2. NET Core
      后续发展路线图

      • 1.2.1.
        已知主要版本的发布时间表
      • 1.2.2. NET Core
        发展历程
    • 1.3. NET Core 或 .NET Framework
      ?

      • 1.3.1.
        概述
      • 1.3.2. 选择.NET Core 还是.NET
        Framework
    • 1.4.
      总结

微软方面表示,通过 .NET Core 3.0,他们现在已具备轻松移植现代 workload
所需的所有技术,无论是桌面应用、移动应用、控制台应用,网站还是云服务。为此,他们计划将不再把
.NET Framework 上已有的技术移植到 .NET Core
3.0,并考虑使用 MIT
协议来开源不打算移植到 .NET Core 3.0 的 .NET Framework 代码库。

当然不移植API并不是说我们在使用新技术方面没有任何机会,只是这些技术不会在.NET
Framework代码库中出现。

这在社区引发了诸多疑惑和争论。进行剧烈变更的原因显而易见:.NET Framework
4.x已经无法充分发挥最新的技术的威力,而且无法完全满足开发跨平台,云化的大规模应用需求,而一个全新的框架可以让.NET开发者以更简单、更直接的方式来开发Web服务与应用。然而,大家普遍感到担忧。如果把所使用的第三方软件代码库升级到最新版本,然后导致不能向下兼容的问题,这是开发者最大的噩梦。迁移的问题看起来无比艰巨,甚至毫无可能,在github社区上大家提出了迁移思路,微软dotnet团队在统一.NET
三大平台的基础上,让我们的迁移更加简单,能充分享受到.NET
Core的各种优点。

.NET Core 2.0 是您的最好选择吗?。本月14日,微软发布.NET Core 2.0 正式版,它的发布意味着.NET
Core平台更加成熟,也预示其更美好的未来。本文将分析.NET Core
的特性以及未来发展方向,为开发人员选择在何种平台开发程序提供参考。

当然不移植 API
并不是说我们在使用新技术方面没有任何机会,只是这些技术不会在 .NET
Framework 代码库中出现。

下面我们来看看.NET Core和.NET Framework的发展历程。

Web的进化–大前端时代

1.1. Net Core 2.0 特性

下面我们来看看 .NET Core 和 .NET Framework 的发展历程。

从.NET Core
1.0开始,它只有一个非常小的API集合,其中仅包含大约1.8万个.NET Framework
API。通过.NET Standard 2.0,微软试图在.NET Framework, .NET
Core和Xamarin之间共享代码,因此.NET Core 2.0提供了大约3.8万个.NET
Frameworks API。此外,微软还构建了兼容性套件包——Windows Compatibility
Pack,而该套件包又让.NET Core增加了大约2.1万个.NET Framework
API。至此,前后大约有6万个API移植到了.NET Core。

近年来,Web已经发生了大幅度的进化,以NodeJs为代表的,我们知道,Javascript最初开发的这门语言的时候,目标只是用来编写简单的客户端脚本,但是随着时间的推移,它的角色已经发生了很大的转变。现在,我们可以利用HTML5提供的API来处理音频和视频文件,用全双工通道和外部服务进行通信,传输和处理大块原始数据,如此等等。我们已经来到了大前端时代,大前端时代是WEB统一的时代,利用html5或者6甚至7,不但可以开发传统的网站,做炫酷的网页动态效果,更可以采用BS架构应用程序、开发手机端web应用、移动端Native应用程序、智能设备(比如可穿戴智能手表,可穿戴智能衣服)等。

1.1.1. NET Core平台是开源的

.NET Core是.NET Foundation的一部分,如下图:

www.9778.com 1

.NET
Foundation是一个围绕.NET开发框架,并不断创新的社区。微软的另一大进步就是使ASP.NET
Core开源。由于它是一个开源平台,您可以更好地控制使用和修改它,并且其代码的透明度可以为您自己的基于.NET
Core的项目提供信息和灵感。此外,您和您的伙伴可以更快地更正错误和规避安全风险,使.NET
Core更安全。.NET
Core更稳定,因为该平台工具的代码将始终保持公开。整个框架源和包可以在GitHub站点上找到。

从 .NET Core 1.0 开始,它只有一个非常小的 API 集合,其中仅包含大约 1.8
万个 .NET Framework API。通过 .NET Standard
2.0,微软试图在 .NET
Framework, .NET Core 和 Xamarin 之间共享代码,因此 .NET Core 2.0
提供了大约 3.8 万个 .NET Frameworks API。此外,微软还构建了兼容性套件包
—— Windows Compatibility
Pack,而该套件包又让
.NET Core 增加了大约 2.1 万个 .NET Framework API。至此,前后大约有 6
万个 API 移植到了 .NET Core。

而在最新发布的.NET Core 3.0中,微软又增加了WPF和WinForm,因此将.NET
Framework API移植到.NET Core的总数超过了12万,比.NET Framework
API总数量的一半还多。

ASP.NET Core作为.NET
Core平台上的Web服务开发框架也是顺应大前端时代进行设计,ASP.NET
Core是模块化,内置依赖注入,可集成任意前端框架的完全开源的Web平台,统一了ASP.NET
MVC/WEB API/SignalR的编程模型。

1.1.2. 跨平台

除了使其成为开放源码外,微软已经不遗余力地使其跨平台。开发人员将能够在Mac,Linux或Windows系统上开发应用程序。事实上,它还引入了专门为Mac和Linux用户提供的新的代码编辑器“Visual
Studio Code”。

而在最新发布的 .NET Core 3.0 中,微软又增加了 WPF 和
WinForm,因此将 .NET Framework API 移植到 .NET Core 的总数超过了 12
万,比 .NET Framework API 总数量的一半还多。

这里还需要指出的是,微软特意强调他们在.NET Core中添加了大约6.2万个.NET
Framework中没有的API,因此如果仅比较API的总数,那么.NET
Core的API数量约占.NET Framework API的80%。

如果在.NET Framework
4.x/Mono平台上来适应大前端时代,内部实现会变得相当复杂。因为框架已开始压根就不是基于这样的一个时代进行设计的。想想我们哪笨重的WebForm框架是VB/Dephi流行的重客户端时代的产品,微软硬把他搬到了Web上,所以ASP.NET
Core已经不支持Web Form,ASP.NET
MVC平台是微软为适应Web时代重新设计的一个开发平台,从ASP.NET MVC 1.0
进化到ASP.NET MVC
6.0也就是这个Web的进化过程,在这个进化过程中,针对WEB的不同场景出现了三个平台MVC,WEB
API和SignalR。我们已经来到了大前端时代,所以ASP.NET团队考虑重新设计这个平台。

1.1.3. 灵活部署

.NET
Core的这一功能可帮助开发人员灵活部署:作为应用程序(FDD-框架依赖部署)的一部分,或作为全新的安装(SCD-独立部署)
。FDD允许您使用较小的部署包最小化内存和磁盘空间的使用,而SCD则可以完全控制项目部署(包括.NET
Core库和运行时)。

www.9778.com 2

微软表示.NET的未来将基于.NET Core,在Build
2019大会上,微软宣布AppDomains、远程处理、Web Forms、WCF
server以及Windows Workflow都不会移植到.NET
Core。目前也不再计划将任何.NET Framework技术移植到.NET
Core上。前面提到微软会开源不打算移植到.NET Core 3.0的.NET
Framework代码库,希望借此为社区创造更多OSS项目尽一份力量。

云计算时代

1.1.4. 模块化架构

此功能可帮助开发人员根据项目的要求仅使用必需的软件包。模块化架构有助于升级其跨平台兼容性。因此,开发人员现在可以设计轻便,高效和强大的应用程序。与以前的版本相比,新版本相对更轻,更小,这有助于加快开发过程。对文件系统进行了较大改变,将有助于搭建健壮的开发环境。

这里还需要指出的是,微软特意强调他们在 .NET Core 中添加了大约 6.2 万个
.NET Framework 中没有的 API,因此如果仅比较 API 的总数,那么 .NET Core
的 API 数量约占 .NET Framework API 的 80%。

例如,目前已经有两个基于此的社区项目诞生——CoreWF和CoreWCF。

近年来,我们已经进入云计算时代,在云平台的PaSS和SaSS上也是发生了大幅度的进化,以docker为代表。微软的Azure平台,google的GAE等等各大云计算厂商都提供了PaSS平台,我们的应用程序要迁移到这样的平台上都需要进行重写。Docker,给云计算带来一场革新,Docker可以被认为是互联网的集装箱,可以灵活地封装软件,令其更快速地传播。这对现代互联网来说是一件大事,因为软件都会运行上成百上千的机器上。Docker可以改变我们开发软件的方式,令每个人都能便捷地利用大量的运算能力。Docker可以让开发者专注于开发软件,不需要考虑在哪里运行自己的软件,这才是云计算的发展方向。开发者考虑应用本身就足够了。

1.1.5. 命令行工具

与以前的版本相比,新版本更轻,更小,这有助于提高开发效率。为了搭建健壮的开发环境,文件系统作了较大变化。可以在名为DNVM或Dot
Net版本管理器的命令行访问每个可能的产品方案。该命令行可以方便地更新和配置.NET运行时。这是.NET执行环境的补充。命令行的另一个好处就是它与平台无关,开发人员不需要一次又一次地学习工具链。一旦熟悉其使用,就可以在任何其他支持的平台或界面上使用相同的方式。

微软表示 .NET 的未来将基于 .NET Core,在 Build 2019 大会上,微软宣布
AppDomains、远程处理、Web Forms、WCF server 以及 Windows Workflow
都不会移植到 .NET Core。目前也不再计划将任何 .NET Framework 技术移植到
.NET Core 上。前面提到微软会开源不打算移植到 .NET Core 3.0 的 .NET
Framework 代码库,希望借此为社区创造更多 OSS 项目尽一份力量。

.NET
很难进入以docker为代表的云计算开发平台,特别是Windows不支持Docker,因为那完全是互联网服务的基石–Linux系统才有的技术,微软为了适应这样的云计算潮流,在Windows
Server 2016/Windows 10上支持了docker,也重新开发跨平台.NET
Core的应用运行平台。.NET实际上是一系列框架,每个框架针对一个特定平台,而且归不同的微软团队所有,这在API和实现方面都不可避免地产生了差异。.NET
Core是.NET
Framework的一个新的分支,旨在为特定于平台的扩展提供一个共同的基础。每个扩展提供只能用于特定应用程序模型的API,例如,面向.NET本地应用程序的WinRT互操作扩展或者面向ASP.NET
Core应用程序的MVC。这个共同的层称为统一基类库(BCL),它位于一个包含.NET运行时的薄层之上。.NET
Core带来的另外一项有趣的变化是使用NuGet作为基本的交付系统。.NET
Core将会作为一个细粒度的包的集合交付,每个包对应一个程序集。同时,微软将提供.NET
Core分发包。本质上,它只是经过微软测试的、特定.NET版本的所有包的快照副本,用于那些不需要额外的自由进行NuGet包混搭的场景。NuGet的使用以及向更加模块化的设计转变使“.NET
Core平台有可能转变成一种应用程序本地框架。”如此一来,每个应用程序将只需要部署框架中它需要的部分。这样做的主要好处是,当应用程序需要升级.NET
Core时,将不会破坏与其它现有应用程序的兼容性,而升级整台机器共享的.NET
Framework就会如此。

1.1.6. 云支持

ASP.NET Core
是率先开发出保持云集成的功能。因为它支持基于云的配置,所以云端初始化设置允许开发人员将其应用程序方便发布到云端。

例如,目前已经有两个基于此的社区项目诞生
—— CoreWF 和 CoreWCF。

从.NET Framework 4.x/Mono中学习到的经验

1.2. NET Core 后续发展路线图

(文/开源中国)    

为了顺应潮流,框架不得不进行重新实现,但是有一点我们必须牢记:我们并非白手起家,我们拥有从.NET
Framework 4.x/Mono
框架中所学到的经验。自从2009年以来,并非只有Web进化,我们也在构建越来越复杂的应用。今天,云化的应用不再是标新立异之举,而更像是所有业务型Web应用的标配。

1.2.1. 已知主要版本的发布时间表

版本  发布时间
1.0 RC1 2016年2月15日
1.0 RC2 2016年5月16日
1.0 2016年6月27日
1.1 2016年11月16日
2.0 2017年8月14日
2.1 2017第四季度

利用.NET Framework
4.x/Mono,我们已经可以构建高效、大规模的云应用。然而,在大量的案例中,我们发现了它有很严重的缺陷,特别是中国发生的大量互联网公司不断的从.NET平台迁移到Java平台,各大云平台厂商也都不支持.NET
Framework平台,只有可怜Windows
Azure支持。为了满足这些新的需求,微软.NET团队从社区中吸取了大量的经验,开始运用全新的思路进行设计,我们在看到.NET
Core提供的新特性的同时,也应该看到它是根据.NET Framework 4.x特别是Mono
项目的经验发展而来的,然后再想一想,在过去几年中,那些困扰我们.NET开发者的问题是否被解决掉了。

1.2.2. NET Core 发展历程

** RC1 **

2016年1月 ASP.NET 5 改名 ASP.NET Core 1.0 ,所有名字变动如下图:

www.9778.com 3

1.0 RC2

.NET Core横跨各平台:,也就是说所有基于.NET Core
构建的应用模型(比如:ASP.NET Core, Console Apps 和 class
libraries)不仅可以运行在Windows系统之上,同时也可以运行在OS X 和
Linux系统之上。

1.0

微软团队提供的下载中(https://www.microsoft.com/net/download)包含了
.NET Core Runtime, .NET Core SDK, .NET Core VS Tooling (包括 Web
开发工具), .NET Core Windows Server Hosting, 以及更新的 NuGet ASP.NET
Core 1.0 和 Entity Framework Core 1.0 包。微软还发布了用于创建 .NET Core
项目的 Visual Studio 和 Visual Studio Code 扩展,以及 .NET
Documentation(www.9778.com,)。

1.1

.NET Core 1.1 发布,这个版本支持有效期三个月,后续有变动。
11/16 .NET Core 1.1 RTM 版发布。对应发布 ASP.NET Core 1.1 、EF Core
1.1。Visual Studio for Mac 也一同发布。可以通过Visual Studio 2015,
Visual Studio 2017 RC, Visual Studio Code and Visual Studio for the Mac
创建 .NET Core 1.1 的应用。

2.0

受Visual Studio 2017 15.3 版本支持,并引进了新的 Razor Pages
用户界面设计范例。对于ASP.NET
Core来说,这个版本主要简化了部署,提高了预加载页面性能.人们更关注配套的.NET
Core 2.0平台带来的变化:

  • 降低入门及学习的障碍,.NET Standard
    2.0通过标准化共享API,可以轻松地跨.NET Framework,.NET
    Core和Xamarin共享代码。
  • .NET Framework 4.6.1支持.NET Standard 2.0,.NET Standard 2.0
    添加了许多.NET Framework 4.6.1 支持的API,以及.NET Standard 2.0
    自己特有的API
  • .NET Standard 2.0 添加了 14,994 个.NET Framework 4.6.1已经支持的API
  • .NET Standard 2.0 只有 43 个 .NET Framework 4.6.1不支持的API
  • .NET Standard 2.0 将是.NET Standard 1.6的超集。 换句话说,.NET
    Standard 2.0和1.x不会发生突破性的变化。
  • .NET Framework兼容模式: 允许.NET Standard项目引用.NET
    Framework库,利用.NET的历史遗产,便于开发平台从.NET
    Framework迁移到.NET Core.

最终可以理解为.NET Core 2.0 将是等价于 .NET Framework
4.6.1,同时既有的.NET Framework代码可以很轻松的移植到.NET Core平台

统一的编程模型

1.3. NET Core 或 .NET Framework ?

我们在.NET Framework/Mono上有4个Web编程模型,ASP.NET  WebForm、ASP.NET
MVC 、ASP.net Web API、
SignalR。对Web开发的不同场景需要使用不同的编程模型,让我们学习的成本很高,导致这4个编程模型中,很多的开发人员只会其中的一部分,特别是SignalR很多人都不知道。微软也一直在推动One
ASP.NET战略,请看下面这张图:

1.3.1. 概述

.NET Framework支持Windows和Web应用程序。今天,您可以使用Windows
Forms,WPF和UWP在.NET Framework中构建Windows应用程序。ASP.NET
MVC用于在.NET Framework中构建Web应用程序。

.NET
Core是为所有操作系统(包括Windows,Mac和Linux)构建应用程序的新型开源和跨平台框​​架。.NET
Core支持UWP和ASP.NET Core,UWP用于构建Windows
10目标Windows和移动应用程序,ASP.NET
Core用于构建基于浏览器的Web应用程序。通过下图您能看到.NET
Core和以前的.NET Framework的主要功能区别:

www.9778.com 4

同样的ASP.NET Core 与 传统的 ASP.NET 也有较大区别,如下图所示:

www.9778.com 5

www.9778.com 6

1.3.2. 选择.NET Core 还是.NET Framework

产品需求 .Net Core/Framework
使用Windows Forms和WPF的Windows客户端应用程序 .NET Framework
使用到WCF,WF等库的应用程序 .NET Framework
需要使用的第三方.NET 库或NuGet包不能用于.NET Core .NET Framework
需要使用不可用于 .NET Core 的 .NET 技术 .NET Framework
需要使用不支持 .NET Core 的平台 .NET Framework
预配置的环境和系统 .NET Framework更好
对Dockers容器支持 都支持,但.NET Core更适合
微服务 都可以,但.NET Core更适合
跨平台需求 .NET Core
需要高性能和可扩展的系统 .NET Core
需要按应用程序级别选择并行的 .NET 版本 .NET Core

我的应用程序往往是混合的,不仅包括Web Form,MVC还包括SignalR和 Web
API,我们的应用程序搞得很复杂,ASP.NET Core重新设计,把ASP.NET
MVC、ASP.NET Web
API和SignalR的编程模型统一,直接废除过时的WebForms,让我们只需要使用一个统一的模型进行Web开发。同时针对我们的大前端时代的特点,让我们可以很轻松的集成任意的前端框架。

1.4. 总结

.NET
Core平台自2016年诞生到现在发展很快,这不稀奇.在它出生前微软就积累的多年.NET
Framework经验.从以上我们能看出微软的策略:

  • 第一步最重要的是实现跨平台
  • 第二步是使其具有并超越当前.NET Framework的能力
  • 第三步是实现一统各平台开发和运行环境,包括各端(服务器,手持设备,IOT等等)

目前看第一步完成度很高,第二步完成了70%(按API数量实现).第三步也一直在做.我们能从微软的发展路线中看到一个美好的前景,即用.NET的语言给各种设备写一遍程序就足以应付产品需求,这是多方共赢的局面。我们也由衷的希望.NET
Core有一个更加美好的未来。


作者:帅虫哥 出处:

依赖注入

在面向对象的领域里,依赖注入是面向对象的五大原则之一,在.NET
Framework/Mono的社区里存在大量的Inversion of
Control(IOC)机制的框架。依赖注入可以带来很多好处,比如:易测试性,更好的代码结构和模块化,以及更简洁明了。虽然在.NET
Framework/Mono框架内部已经带了一个MEF,并不是我们的必选项,在.NET
Core中中可以说是用了全新的IOC模板,定义在Microsoft.Extensions.DependencyInjection下。提供了一套标准的接口。并提供了默认实现。并且大范围使用着,处处都体现着IOC的设计思想。

开源和跨平台

在 GitHub 上,与 .NET Core
相关的代码库有一百来个,分布在多个账户中。来自世界各地、包括中国的大量开发者都参与了
.NET Core
的开发过程:开发团队会每周与社区跟进进度、讨论计划,随时在线上回答其他开发者的提问,合并其他开发者贡献的代码。笔者也有幸见证这一过程,并实际参与到其中几个项目的贡献中。

对跨平台的需求是真实存在的:我们使用 Windows 或 macOS
从事开发工作,而使用 Linux
系统作为服务器环境;我们开发一套运行在服务器上的软件产品,希望将服务器平台的选择自由留给客户……因此对于现代化的轻量级开发技术栈而言,跨平台也成为一个基本要素。典型的轻量级开发平台大多是基于动态语言的,比如
PHP、Python 或
Node.js,这类动态语言正是由于“动态语言”的特性,在一些场合显得过于灵活、难以掌控,在工程的内建质量和开发效率上取得平衡并不容易。

www.9778.com 7

对于 .NET Core 来说,跨平台这个目标并没有多少历史包袱,.NET Framework
只能运行在Windows平台上,Mono项目是个运行多年的开源社区项目。在开发 .NET
Core
本身的过程中,开发团队很早就使用了持续集成的实践来保障代码针对多个平台的兼容能力。在开发进程中,团队同步维护多个示例项目,例如经典的
MusicStore,及时回归核心特性、保障稳定性。从两年之前开始,就陆续有
alpha、beta 和 RC 版本发布出来,让开发者提前体验到新运行时的同时,也借助
GitHub 开源平台及早收到来自社区的监督和帮助。借助这些一系列的措施,.NET
Core 跨平台的能力有着充分的事实保障

高生产力平台

新打造的 .NET Core
有一些关键特性,颇具吸引力。例如与特定操作系统无耦合,可编译为原生平台代码,运行效率极高;完全模块化,
内置包管理器用于管理依赖项;提供完整而标准化的命令行工具集,与 Docker
等新近技术能无缝集成。它虽然是全新的开发平台,却直接使用 C#
这样的明星静态语言的最新版本作为开发语言,充分运用 .NET
平台十几年积累的设计理念,汲取过去数十年各种编程语言和开发模型中的精华,才最终锻炼成适用于下一代开发工作的新平台。

一套面向非 Windows
环境的生态系统工具也在同期陆续地发布了出来,包括跨平台的编辑器 Visual
Studio Code,高性能 Web 服务器 Kestrel
以及持续集成编译工具 Cake 等,Visual Studio 2017
目前正在Preview阶段,马上就会迎来RC,对我们的Windows下开发工具的支持上更加完善。

在国外,不少开发者已经在积极响应 .NET Core 的路线,发布基于 .NET Core
的运行时的类库,提供兼容 .NET Core 的 SDK 等。常用的
XUnit.net、Moq、Autofac、MongoDB 和 RavenDB
等流行的类库和工具已经提供了对 .NET Core
的支持,或正在积极地开发新的版本。在国内 .NET Core
在社区中的交流学习也正在稳步铺开。很多开发人员已经着手文档翻译、源码学习,以及实践分享等工作,也有不少的开源项目。在博客园网站上已经出现不少关于
.NET Core 的文章,而在我运营的微信公众号“dotNET
跨平台”中,一直在给大家优先推送.NET Core的文章和资讯。