.net core快速上手

by admin on 2020年2月9日

目前 .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完全不同的框架。

微软方面表示,通过 .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的各种优点。

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

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

Web的进化–大前端时代

下面我们来看看 .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应用程序、智能设备(比如可穿戴智能手表,可穿戴智能衣服)等。

从 .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的编程模型。

而在最新发布的 .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

微软表示.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 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可以让开发者专注于开发软件,不需要考虑在哪里运行自己的软件,这才是云计算的发展方向。开发者考虑应用本身就足够了。

微软表示 .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就会如此。

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

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

(文/开源中国)    

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

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

统一的编程模型

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

图片 2

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

依赖注入

在面向对象的领域里,依赖注入是面向对象的五大原则之一,在.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,这类动态语言正是由于“动态语言”的特性,在一些场合显得过于灵活、难以掌控,在工程的内建质量和开发效率上取得平衡并不容易。

图片 3

对于 .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的文章和资讯。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图