.net core快速上手

by admin on 2020年3月15日

微软将对 ASP.NET Core
进行重大更新,其中包括项目与框架的整合、与
.NET Core
更紧密的集成,以及与第三方开源套件的集成,这些改进都将会协助开发者更快速的完成开发工作。

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

项目在 ASP.NET Core 上引用和运行的方式随着版本的迭代发生了变化。在 1.0
中,ASP.NET Core 本身就是一个“包”,并且像任何其他 NuGet
包引用一样出现在项目中。这有利有弊,随着时间的推移,这个模型有了新的发展,在
2.1 中,ASP.NET Core 最终演变为可作为 .NET Core 的“共享框架”。而 ASP.NET
Core 3.0 则持续朝这个方向进行改变 —— 将从 3.0 中的 ASP.NET Core
共享框架中删除一些子组件:

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

  • Json.NET (Newtonsoft.Json)

  • Entity Framework Core (Microsoft.EntityFrameworkCore.*)

Web的进化–大前端时代

由于 .NET Framework 未来从 .NET Core
获得的新平台和语言特性将会变少,且因为 .NET Framework
的更新策略,这将使已有的应用程序受到影响。为了确保 ASP.NET Core
能够充分利用 .NET Core 的改进,从 3.0 开始,ASP.NET Core 将只支持在
.NET Core
上运行,目前仍在
.NET Framework 上使用 ASP.NET Core 的开发者,可以使用 2.1 LTS
版本以继续获得完全的支持,微软对 2.1 的支持将持续到 2021 年。

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

关于 ASP.NET Core 3.0 只支持运行在 .NET Core 上的计划,ASP.NET
Core 项目的高级软件工程师在 GitHub 发布了一个公开
issue为大家提供讨论的渠道。

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

关于 ASP.NET Core 3.0
详细的更改计划,请查看官方博客的公告。

如果在.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团队考虑重新设计这个平台。

(文/开源中国)    

云计算时代

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

.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就会如此。

从.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战略,请看下面这张图:

图片 1

我的应用程序往往是混合的,不仅包括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,这类动态语言正是由于“动态语言”的特性,在一些场合显得过于灵活、难以掌控,在工程的内建质量和开发效率上取得平衡并不容易。

图片 2

对于 .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地图