.NET Core 很酷,你不得不知!

我一直回想我的第一篇博文,那是关于多个服务的服务器平台的详细教程,它使用 GitLab CI 在 AWS 上,当时使用单个命令行进行部署, 至今回想,令人感觉很酷。

image

前几天,我偶然听说一些软件公司的 HR 在招聘原则上拒绝任何希望使用.NET 的候选人,原因如下:
.NET 是一个古老的封闭式生态系统,与其他更性感的开发平台截然不同,如 NodeJS 或 RubyRails,这些开发平台更加灵活和开放。.NET 实际上有点像 Java,但是,JAVA 拥有强大的开源生态圈、而且可以跨平台,关键的是 Java 不被邪恶的微软一家垄断。

当时,我正在我的个人 MacBook 上使用 C#和.NET Core 开发 Web 应用程序,我使用 Lambdas 函数,Linux EC2 和 Docker 容器在 AWS 上使用 GitLab 进行部署。我甚至 5 年前曾经在.NET Core 的官方开源 Github 存储库中 Pull 了一些代码和测试,这些存储库仍在其上。

毋庸置疑,我作为一名.NET 开发人员,听到这一点消息,我的内心开始觉得不舒服。

所以在此,我想做几个 demo,来告诉大家可以在 C#和.NET Core 中轻松快速地开发、部署,就像我们在 JavaScript 和 NodeJS 中所做的那样: 跨平台、开源、一个命令行搞定一切。

.NET Core 平台是什么?

当我们谈论.NET Core 平台时,事情很快变得比较复杂,在这里,我只引用官方文档:

  • .NET Core 运行时:类型系统,程序集加载,垃圾收集器,本机互操作和其他基本服务。 .NET Core 框架库提供原始数据类型,应用程序组合类型和基本实用程序。
  • ASP.NET 运行时:提供了一个框架,用于构建基于云的互联网应用程序,例如 Web 应用程序,IoT 应用程序和移动后端。
  • .NET Core CLI: 提供工具和语言编译器(Roslyn 和 F#)支持.NET Core 开发人员体验。
  • dotnet 工具:用于启动.NET Core 应用程序和 CLI 工具。它选择并托管运行时,提供程序集加载策略并启动应用程序和工具。

以上内容总结:

  • 运行时,可以通过执行.NET Core 的二进制文件。
  • ASP.NET Core 是一个框架和一组库,可以用来构建 Web 应用程序和 Web API。
  • .NET Core CLI 与其他平台 CLI 类似,允许创建,构建,发布,设置和支撑项目以及其他操作。

Hello world,动手操作吧:

我的目标是向您展示如何快速轻松地使用.NET Core 来创建应用程序和网站,就像使用 NodeJS 或 RubyRails 一样 – 让我们开始吧:

在 Linux 安装很简单 ; 只需点击此链接并选择您的发布,同时注册 Microsoft 密钥和 feed。
安装必要的软件包需要大约三、四个命令。

在 Linux Ubuntu 上,从终端看起来的样子:

wget -q https://packages.microsoft.com/config/ubuntu/19.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install dotnet-sdk-2.2

安装完成后,通过如下命令进行测试是否成功:

dotnet --version
> 2.2.300

在 MacO 或 Windows 上安装.NET Core 更简单:只需从官方 Microsoft 门户下载安装包,安装程序为您自动完成这些工作,通常只需要几分钟。

Hello World!

在众所周知的程序教程中,首先创建一个控制台应用程序:显示 Hello World!。

通过命令行来创建文件夹,然后通过命令行创建控制台应用程序工程:

mkdir hello-world
cd hello-world
dotnet new console

你将得到如下文件结构:

hello-world
├── bin
├── obj
├── hello-world.csproj
├── Program.cs

您可以忽略 bin 和 obj 文件夹,这些文件夹仅用于构建和调试。 事实上,我在 VSCode 和 Git 上都忽略了它们。

.csproj 文件包含有关运行时,包,版本和其他项目配置属性的信息。 它默认很小。

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>

<OutputType>Exe</OutputType>

<TargetFramework>netcoreapp2.2</TargetFramework>

</PropertyGroup>

</Project>

最后,我们最重要的文件:Program.cs。

using System;
namespace HelloWorld
{
  class Program
  {
    static void Main(string[] args)
    {
        Console.WriteLine("Hello World!");
    }
  }
}

在这里,没有什么是棘手的 – 你有你的默认命名空间。 通过静态方法 Main()声明主入口点的类。 类或命名空间可以更改为您想要的任何内容,也不需要公开,Main 方法也不需要。 这里的类是内部的,方法是私有的。

唯一的限制是至少要有这个静态 Main 方法。 甚至参数都是可选的,但它们的存在是为了通过命令行执行提供对参数的访问。

现在,让我们运行应用程序:

dotnet run
> Hello World!

.NetCore, 就这么简单!

要获得可在具有.NET Core 运行时(此处为 2.2 版)的任何环境中部署的应用程序的发行版,只需按如下方式发布应用程序:

dotnet publish -c Release -o dist

生成的 dist 文件夹应如下所示:

dist
├── hello-world.deps.json
├── hello-world.dll
├── hello-world.pdb
├── hello-world.runtimeconfig.json

可以删除 hello-world.pdb,因为它仅用于调试目的,但默认情况下会生成 pdb,即使在发布模式下也是如此。 您可以通过将此代码段添加到 hello-world.csproj(在标记下)来禁用此自动生成 pdb。

<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<DebugType>None</DebugType>
<DebugSymbols>false</DebugSymbols>

</PropertyGroup>

hello-world.dll 就是是您编译的代码,使用此运行时命令可执行:

dotnet hello-world.dll

deps.json 和 runtimeconfig.json 文件分别用于处理其他包的依赖关系和配置运行时。

最后,您可以使用 dotnet publish 运行时标识符目录轻松地在发布特定平台:

dotnet publish -c Release -r win-x64 -o dist/win-x64
dotnet publish -c Release -r osx-x64 -o dist/osx-x64
dotnet publish -c Release -r linux-x64 -o dist/linux-x64

Hello Web !

好吧,这很酷,我们很容易在控制台上写了一行,但是有些网络 Web 呢? 好吧,这也很容易做到!

首先,让我们添加 ASP.NET Core 的包:

dotnet add package Microsoft.AspNetCore

引用新包就像为 NodeJS 导入 npm 包一样。
这个包将允许我们配置,构建和运行一个简单的 WebHost 程序。 这可以在 Main()方法中的单行代码中完成。

生成的 Program.cs 应如下所示:

using System;
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;


namespace HelloWorld
{
    class Program
    {
        static void Main()
        {
            Console.WriteLine("Hello World!");


            WebHost.CreateDefaultBuilder()
                .Configure(app => app.Run(context => context.Response.WriteAsync("Hello World!")))
                .Build()
                .Run();
        }
    }
}

您可以使用与上面相同的命令来运行和构建应用程序:

dotnet run

现在打开你的浏览器,转到 http:// localhost:5000,享受这个简洁的 Hello World, 网页:

本文到此为止,本次实践完全基于 Macbook 电脑,在 Linux 命令行下完成,很酷,不是嘛。

在阅读完之后,我真的希望你对.NET Core 的看法有所改变:微软在多年前对.NetCore 进行开源, .NetCore 不仅仅只支持 Windows、而是可以跨平台和开源,令人兴奋的是是,到 2019 年秋天,.NET Core 3.0 即将问世,作为技术从业人员,这些惊喜的变化你不得不关注。

关于WCF、WebAPI、WebService之间的区别总结 分布式通信技术(Distributed Communication Technologies)浅析

关于WCF、WebAPI、WebService之间的区别总结
分布式通信技术(Distributed Communication Technologies)浅析

早在1996年Gartner就前瞻性地提出了面向服务架构的思想(SOA),SOA 的走红在很大程度上归功于 Web Service 标准的成熟和应用的普及。 Service Oriented Ambiguity 中文一般理解为:面向服务架构,简称SOA,这个概念算得上微服务的鼻祖了。 SOA 的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的、粗粒度、松耦合、无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。 SOA 本质上是服务的集合。 在分布式通信技术选型中,就本人曾经使用过的基于微软平台的分布式通信进行概述,先明确一下分布式框架的三个基本需求:
  • 客户端: Web、Android、IOS、跨平台(Java 开发的系统和.NET 开发的系统可以通信)
  • 服务端:部署在Windows、Linux
  • 合约(Contract):传递的格式(REST,Json、SOAP、XML)、通信协议(HTTP、XML-RPC、TCP)、消息超时设置、消息包大小
要打造分布式平台,各家技术栈多有不错的实践,这里重点说一下微软技术栈下,丰富的技术选型:
  • .NET Remoting (15年前技术,目前已经失传)
  • Web Service (ASMX, ASP .NET Web Services,15年前技术,维护项目依然存在)
  • WCF (Windows Communication Foundation,10年前技术,维护项目中比较多)
  • Web API (5年前技术开始火起来,和跨平台需求密不可分,最近3年的新需求大部分迁移在这里了)
下面展开来说:

.NET Remoting

是2.0时代的产物, 即2004年的技术,我还没有机会实战过。在微软Roadmap中已被WCF取代(.NET Remoting做得到的事,理论上WCF都可以实现) 依据微软一份,WCF在效能上比ASP.NET Web Service快了25%-50%,比.NETRemoting快25%,弃.NET Remoting改用WCF将有性能能上的突破。 详见报告链接

Web Service

在很早前开发WebForm ASP.NET中用的比较多,因此可以将 Web Service 理解为一个基于 HTTP 协议开发的上层应用程序 Web service 是一个平台独立的,低耦合的,自包含的、基于可编程的 Web 的应用程序,可使用开放的 XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的互操作的应用程序。 Simple Object Access Protocol,中文为简单对象访问协议,简称 SOAP。
1、它是基于SOAP协议的,数据格式是XML (SOAP )

2、只支持HTTP协议

3、它不是开源的,但可以被任意一个了解XML的人使用

4、它只能部署在IIS上 

SOA 不是 Web Service,Web Service 是当年最适合实现SOA的技术。

WCF

WCF是取代Web Service及.NET Remoting的接班人,我记得这个是微软2010年开始力推的技术。 我第一次是用WCF是2012年,做一个电信级项目,结合微软吹水的Silverlight技术(Silverlight技术,2013年底该技术被微软安乐死了,again!)
1、这个也是基于SOAP的,数据格式是XML

2、这个是Web Service(ASMX)的进化版,可以支持各种各样的协议,像TCP,HTTP,HTTPS,Named Pipes, MSMQ.

3、WCF的主要问题是,它配置起来特别的繁琐!!! (此处特别强调了3个感叹号 )

4、它不是开源的,但可以被任意一个了解XML的人使用

5、它可以部署应用程序中或者IIS上或者Windows服务中

WCF门槛有些太高,仅仅在Windows平台开发,而且配置文件比较复杂(WCF 客户端\WCF 服务器端,仅Binding、Behavior的复杂度就能单独写一篇文章,踩过不少坑,都是泪。) 众所周知,微软.net技术未来是.netCore,成熟的.NetCore3 2019年底就可以应用于生产系统了, 但多年来微软一直拒绝将WCF 的服务器端移植到.NET Core, 导致这个分布式技术,面临的极大的技术瓶颈,即若干年后几无可用人才来维护WCF项目,所以大约3年前开始,我知道周围朋友公司的新项目大都避而不谈WCF了。

ASP.NET Web API

随着SOAP 逐渐淡出,RESTful大行其道, Web API火了起来。 微软技术栈的工程实现是 ASP.NET Web API,而且微软建议使用 ASP.NET Core Web API 或 gRPC,它们提供基于跨平台和跨编程语言的 RPC,也能使用 gRPC 来编写代码,并替换掉一些 WCF 服务器服务。
1、一个简单的构建HTTP服务的新框架

2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术

3、不像WCF REST Service.它可以使用HTTP的全部特点(比如URIs、request/response头,缓存,版本控制,多种内容格式)

4、它也支持MVC的特征,像路由、控制器、action、filter、模型绑定、控制反转(IOC)或依赖注入(DI),单元测试。这些可以使程序更简单、更健壮

5、它可以部署在应用程序和IIS上

6、这是一个轻量级的框架,并且对限制带宽的设备,比如智能手机等支持的很好

7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。

WCF 的未来是Web API,而且微软2014年推出开源.NetCore中就有ASP.Net Core Web API,可见重视程度。

分布式技术这么多,我该选谁?

都2019年了,新项目肯定是WebAPI,原因如下:
WebAPI只要有能力发送HTTP Request跟解析JSON,比较符合微服务要求, 跨平台支持。

创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时(比如URIs、request/response头,缓存,版本控制,多种内容格式),你应该选择WebAPI

让你的服务用于浏览器、手机、iPhone和平板电脑时,你应该选择Web API

双工消息模式,过SignalR和WebSockets整合(创建一个支持消息、消息队列、双工通信的服务时)