ASP.NET

ASP.NET 社区成长壮大

此文主要讨论ASP.NET Community本年的里程碑,通过一些列的链接,视频,文章进行概述。

ASP.NET

社区链接地址

Rethinking email confirmation

Managing Cookie Lifetime with ASP.NET Core OAuth 2.0 providers

Build a REST API for your Mobile Apps with ASP.NET Core

IdentityServer4 and ASP.NET Core 1.1

Url culture provider using middleware as filters in ASP.NET Core 1.1.0

Making Application Insight Fast and Secure

Simple SQL Localization NuGet package

Building Application Insights Logging Provider for ASP.NET Core

Generic Repository Pattern In ASP.NET Core

Integration Testing with Entity Framework Core and SQL Server

Bare metal APIs with ASP.NET Core MVC

Accessing HttpContext outside of framework components in ASP.NET Core

Optimize expression compilation memory usage

ASP.NET Core Response Optimization

Angular 2 and ASP.NET Core MVC

Dockerizing a Real World ASP.NET Core Application

Convert ASP.NET Web Servers to Docker with Image2Docker

Sharing code across .NET platforms with .NET Standard

Multiple Versions of .NET Core Runtimes and SDK Tools SxS Survive Guide

Migration to ASP.NET Core: Considerations and Strategies

Updating Visual Studio 2017 RC – .NET Core Tooling improvement

 

成就

.NET Core tooling for Visual Studio 2017 RC已经更新,包括支持:csproj  文件的简化,.NET Core 项目文件使用更简化的语法,更容易阅读。CLI命令行的增加,可以通过命令行删除工程中的文件引用。整体质量的改进,bugs的修复,和xproj 文件改为csproj,NuGet, MSBuild 和ASP.NET Core支持Docker。.NET Core Tooling更多改进here

问答

Question:  最新版的VS 2017 .NET Core tooling更新,在创建新用用程序时候生成csproj文件.还能在工程中使用.json文件后缀?

— 将更有逻辑的文件夹创建方式引入dotnet,他需要找到SDK,他将默认使用的dotnet SDK最新版本,可是使用全局.json 你能使用之前版本的SDK.

Question: 全局.json 是否是 dotnet SDK路由?  checkout this post for reference

— 在当前不是,未来可能会,在内网将支持同步显示SDK的选择器。

C# 图书

Kim Spilker推荐关于C#书

如果你的组织是新手开始写程序,那推荐阅读和学习Begin to Code with C#,本书主要介绍变成的细节和语法基础。从书中你可以学习程序是怎么修炼的,电脑是怎么处理数据的,数据和信息的相关性等。帮助你从零开始学习写程序。塑造良好的程序员习惯。

Rob Miles 的论坛上告诉程序员进行交流。

 

C# 图书S

 

ASP.NET Core

ASP.NET Core提供模块化Middleware组件

ASP.NET Core 引入了中间件(middleware)的概念来定义 HTTP 管道(pipeline)。中间件是一系列组合在一起形成 web 应用程序的组件。这个概念的灵感来源于 OWIN 和 Katana,在 ASP.NET 早期版本中也提供了类似的功能。

一个中间件是 HTTP 管道中的一个组件。中间件逐个执行,并在管道中链式地调用下一个中间件。每个中间件都可以终止调用链。例如,如果认证过程失败,则认证中间件不会再执行下一个中间件。下图说明了执行流程。

ASP.NET Core

除了 ASP.NET Core 中内置的中间件,我们也可以创建新的中间件。如果需要自定义中间件,可以编写一个类,该类中必须包含以 HttpContext 作为第一个参数的方法。这个方法允许增加其他参数,可以通过依赖注入进行解析。下面的类定义了一个日志中间件:

 

public class RequestLoggerMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger _logger;

    public RequestLoggerMiddleware (RequestDelegate next, ILoggerFactory loggerFactory)
    {
        _next = next;
        _logger = loggerFactory.CreateLogger ();
    }

    public async Task Invoke (HttpContext context)
    {
        _logger.LogInformation ("Handling request: " + context.Request.Path);
        await _next.Invoke (context);
        _logger.LogInformation ("Finished handling request.");
    }
}

中间件必须在 Startup 类的 Configure 方法中进行注册才可以执行。

public void Configure (IApplicationBuilder app)
  {
      app.UseMiddleware ();
  }

 

 

一点需要注意的是,中间件的执行顺序依赖于它们添加到管道中的顺序。这就意味着必须花费一些精力确定中间件之间隐含的依赖关系。例如,一个组件要使用会话状态,但是如果它在会话中间件之前执行,则会导致崩溃。

伴随着 ASP.NET Core“为你所用的资源付费”的理念,一些应用程序的性能可能会有所改善,因为只有明确配置的中间件才会执行。该框架不再依赖于 System.Web.dll;组件将以 NuGet 包的形式提供。这也意味着组件的更新将由 NuGet 负责处理,并且每个中间件均可独立更新。

ASP.NET Core

架构系列:ASP.NET Core 1.0 项目结构搭建

我们头开始,从简单的ASP.NET Core 1.0单项目解决方案,逐步添加业务逻辑的约束,从应用逻辑和领域逻辑两方面考虑,从简单的单个项目逐步搭建一个多项目的解决方案。

ASP.NET Core

主要内容:

(1)搭建应用逻辑和领域逻辑都简单的单项目

(2)为应用逻辑复杂的单项目添加应用服务

(3)为领域逻辑复杂的单项目添加领域行为

(4)Application膨胀时,分离Application项目

(5)分离Infrastructure项目

(6)添加Web服务支持

(7)Web服务器负载均衡的支持

(8)其他方面的扩展支持

1.搭建应用逻辑和领域逻辑都简单的单项目

业务逻辑简单,主要的用例和CURD几乎一一对应,没有区分应用逻辑和领域逻辑的必要。

(1)搭建单项目解决方案:Example,项目类型为ASP.NETMVC

(2)添加Application文件夹,添加IRepository<T>接口。

(3)在Application文件夹中添加Domain文件夹,使用POCO作为实体。

(3)添加Infrastructure文件夹,添加Dependency文件夹,添加IContainer和IoCContainer实现,添加Repository文件夹和EfRepository<T>实现。

(4)添加Web文件夹,添加IoCControllerFactory实现,在Controller中通过构造注入IRespository<T>。

2.为应用逻辑复杂的单项目添加应用服务

业务逻辑复杂的原因更多体现在流程控制上而非领域逻辑上,因此我们对上文的项目进行改造。

(1)Application文件夹中添加Service文件夹,通过ApplicationService接口来抽象应用逻辑,在实现ApplicationService接口时通过构造注入IRepository<T>。

(2)在Controller不在直接依赖IRepository,在Controller中通过构造注入IApplicationService。

3.为领域逻辑复杂的单项目添加领域行为

领域逻辑复杂表现在过多的直接通过属性进行实体状态判断并多次赋值,一般情况下这些代码可以通过重构添加到实体。

(1)从ApplicationService中分离出与流程控制无关的代码。

(2)对实体类添加行为,实体类的public方法的定义分离到实体接口中,其他方法为私有方法。

此时的项目结构如图所示:

4.Application膨胀时,分离Application项目

Application 是项目的核心,本身都是业务逻辑相关的代码,即使对其他类库有依赖也可以通过接口隔离方式消除,因此在Application代码膨胀时,无论是应用逻辑 和领域逻辑哪种原因,都应该分离Application项目,更重要的意义在于我们需要对Application项目进行单元测试。事实上复杂一些的项 目,我们一开始构建的就是Application项目及其单元测试。

(1)在解决方案中添加Example.Application项目。

(2)将Example项目中的Application文件夹下的全部文件迁移到Example.Application项目中,这样无需修改命名空间。

(3)修改Example项目添加Example.Application项目的引用。

此时解决方案的结构如图所示:

5.分离Infrastructure项目

分 离Application项目后,由于Infrastructure只单向依赖Application中的接口,因此分离Infrastructure项 目顺理成章。如果是多客户端项目,在分离Infrastructure后可以考虑再从Web项目中分离出单独表现逻辑层Example.WebBase。

(1)在解决方案中添加Example.Infrastructure项目。

(2)将Example项目中的Infrastructure文件夹下的全部文件迁移到Example.Infrastructure项目中,同样无需修改命名空间。

(3)修改项目的引用,添加Example对Example.Infrastructure项目的引用,添加Example.Infrastructure对Example.Application的引用。

此时解决方案结构如图所示:

6.添加Web服务支持

由于Web项目只依赖ApplicationService的接口,这是应有之意。我们添加服务层时只需要提供Web服务类型的IApplicationService接口实现即可。

(1)添加Example.Application.WebApi项目,引用Example.Application项目,封装ApplicationService应用服务。

(2) 添加Example.WebApiApplicationService项目,引用Example.Application和 Example.Application.WebApi项目,实现IApplicationService接口的WebApi版本 WebApiApplicationService。

(3)修改Example项目的依赖注入配置,将IApplicationService的实现配置为WebApiApplicationService。

(4)还要记得将Web项目中配置的ApplicationService的第三方依赖接口的依赖注入配置转移到Web服务项目中。

此时解决方案如图所示:

7.Web服务器负载均衡的支持

添加Web服务器的负载均衡主要解决认证token的问题和Session的问题。

(1)ASP.NET的Forms认证可以通过修改Web.config支持生成同样的用户token。

(2)ASP.NET的Session可以通过自定义SessionStateStoreProviderBase实现分离Session到Session状态服务器或集群。

8.其他方面的扩展支持

无 论是邮件服务、缓存还是数据库,Application都是通过接口隔离了具体的实现,因此我们可以按需添加ApplicationService中定义 的IEmail、ICache、ILogger等的其他实现,再修改依赖注入的配置即可。如果没有采用Web服务,修改Web项目,否则修改Web服务项 目的依赖注入配置。

.NET开源

.NET开源一年及开源一年后ASP.NET贡献情况分析

微软已经开源 .NET framework 的核心部分一年多了,之前 Scott Hanselman 做了一个非常好的源代码分析工具,基于微软的 Power BI 实现。本文也是通过这个分析工具得出的结论,.NET 框架核心部分开源一年多了:

  自从微软开源之后,究竟社区参与了多少?

这里会以 3 个 .NET 生态系统中最主要的三个部分来说明,这些项目也是 .NET 基金会最活跃/最多 star 和最多 Fork 的项目

  1. Roslyn – .NET 编译平台 (“Roslyn”) 提供开源 C# 和 Visual Basic 的编译器,支持富代码分析 APIs。
  2. CoreCLR – .NET Core 运行时,名为 CoreCLR,包括一个基础库 mscorlib。CoreCLR 包括垃圾收集器,JIT 编译器,基础 .NET 数据类型和大量低级别类。
  3. CoreFX –  .NET Core 函数库,包括集合,文件系统,工作台,XML,异步等等。

现有数据

GitHub 自身也有一些内置图表,以下就是整一年中的 Commits per Month:

.NET开源

 

还有一个很清晰的仪表盘可以查看 Monthly Pulse .NET开源

但是要回答那个问题还需要更多的数据,幸运的是,GitHub 还提供一个非常不错的 API,完美的结合了 Octokit.net library 和 LINQPad,这样可以轻松的获取想要的数据。这里有个示例 LINQPad 脚本

但是,即使知道每个月的 “# of Issues” 或者 “Merged Pull Requests” 也没有用,因为不能知道是谁创建了 issue 和提交了 PR。但是 GitHub 还有一个功能,可以识别不同的用户。请看 Roslyn Issue #670,可以清楚的识别用户是项目所有者还是协作者,没有任何说明的就是社区参与人员。

GitHub
GitHub

结果

数据已经到手,结果就在数据里面:

总 Issues 数 – By Submitter

Project Owner Collaborator Community Total
Roslyn 481 1867 1596 3944
CoreCLR 86 298 487 871
CoreFX 334 911 735 1980
Total 901 3076 2818 6795

在这里可以看出,在某些情况下,拥有者和协作者贡献占主导地位。

例如:Roslyn 几乎 60% 的 issues 是拥有者和协作者开启的。但是在另一些方面,社区表现会很活跃,特别是在 CoreCLR,这个项目社区成员开启的 issue 比较多。还有一部分原因是不同的项目,CoreCLR 是 .NET 最明显的部分,包括微软的一些网络框架,.NET 开发者日常开发经常用到,所以社区会有比较多的建议,改进和修复,而且 CoreCLR 是比较有历史的一个库。相对来说,Roslyn 是一比较新的项目,平常比较少用,而且在编译器找错误也是比较困难的。

总合并 Merged Pull Requests – By Submitter

Project Owner Collaborator Community Total
Roslyn 465 2093 118 2676
CoreCLR 378 567 201 1146
CoreFX 516 1409 464 2389
Total 1359 4069 783 6211

但是当我们看合并的 Pull Requests 数,社区成员无疑是参与比较少的,只有大概 12%。但这并不意外,因为不是所有的 pull request 都被接受。首先,项目会使用他自己的机制, “up for grabs”,所以 12% 已经很不错了。h

更新: “up for grabs” 并不是必要的。

每个月的 Issues 数 – By Submitter

.net Pull Request .net Pull Request

issue 标签 Top 20

最常使用的 issue 标签 TOP 20

Top 20 Issue Labels

这是根据结果的一些观察:


开源 .NET 一年后,ASP.NET 贡献情况分析

在之前的文章我们讨论了微软开源 .NET 框架核心部分后一年的社区的贡献程度。本文要继续继续分析这个问题,但是主要关注的是 ASP.NET 生态圈下的项目:

  1. MVC – 构建动态 Web 网站的模型-视图-控制器框架,包括合并 MVC,Web API 和 Web Pages w/ Razor。
  2. DNX – DNX (一个 .NET 执行环境) 包括启动和运行应用所需要的代码,包括编译系统,SDK 工具和原生 CLR hosts。
  3. EntityFramework – 微软为 .NET 新应用推荐的数据访问技术
  4. KestrelHttpServer – ASP.NET 5 基于 libuv 的 Web 服务器

方法论

在上一篇文章把 issues/PRs 创建者分为项目拥有者,协作者和社区成员。但是这会有一些质疑,有一些协作者并不是微软员工。

所以,决定分为以下两种角色:

  • 微软
  • 社区

这是可行的,因为所有微软员工都会在 GitHub 个人信息里面标记为微软员工,比如:

微软  GitHub

 

结果

经过这个调查分析,“issues”超过 60% 是社区成员创建的,合并的“Pull Requests”有超过 30% 是社区成员完成的。但是,这个数据平均值已经被 EntityFramework 项目变得有点不真实,因为 EntityFramework 里面微软员工完成合并的 PRs 比社区成员的多太多,如果忽略这个项目,社区成员完成的 PRs 数可以达到 44%

Issues 创建 (2013 年 11 月 – 2015 年 12 月)

Project Microsoft Community Total
aspnet/MVC 716 1380 2096
aspnet/dnx 897 1206 2103
aspnet/EntityFramework 1066 1427 2493
aspnet/KestrelHttpServer 89 176 265
Total 2768 4189 6957

合并的 Pull Requests (2013 年 11 月 – 2015 年 12 月)

Project Microsoft Community Total
aspnet/MVC 385 228 613
aspnet/dnx 406 368 774
aspnet/EntityFramework 937 225 1162
aspnet/KestrelHttpServer 69 88 157
Total 1798 909 2706

注意:这里包括了 Kestrel Http Server 项目,因为这是非常有趣的一个事例,当前 #1 贡献者并不是微软员工,他是 Ben Adams,在改进内存使用做了很大的贡献。

每个月创建的 Issues - By Submitter 每个月合并的 Pull Request  - By Submitter

 

人们的贡献总和:

不同角色 GitHub 用户对每个项目的总贡献成都,issue 创建和 PR 合并:

Project Microsoft Community Total
aspnet/MVC 39 395 434
aspnet/dnx 46 421 467
aspnet/EntityFramework 31 570 601
aspnet/KestrelHttpServer 22 95 117
Total 138 1481 1619

FSharp

Isaac Abraham 指出了之前那篇文章的一些问题:

.NET 在一年之间开源的部分不仅仅是这么多,还有  F# 编译器和 FSharp.Core。

为了确认这个,大概浏览了一下 FSharp 库:

就像 Isaac 解释的,他们的关系是:

… visualfsharp 是微软的库 Visual F#,另一个是社区所有。前者是直接集成到 Visual Studio 的 Visual F# 工具链;后者是类似 Xamarin 的工具。

这里有一个 (过时) 关系解释图,其他内容请看 http://fsharp.github.io/

FSharp – Issues 创建数 (2010 年 12 月 – 2015 年 12 月)

Project Microsoft Community Total
fsharp/fsharp 9 312 321
microsoft/visualfsharp 161 367 528
Total 170 679 849

FSharp – 合并的 Pull Requests (2011 年 5 月 – 2015 年 12 月)

Project Microsoft Community Total
fsharp/fsharp 27 134 161
microsoft/visualfsharp 36 33 69
Total 63 167 230

总结

 社区越来越多的响应会促使微软开源更多的项目代码。


相关英文原文

Open Source .NET – 1 year later

Open Source .NET – 1 year later – Now with ASP.NET

ASP.NET Core 1.0

ASP.NET 5已终结,迎来ASP.NET Core 1.0和.NET Core 1.0

ASP.NET 在过去的 15 年里是个非常不错的“品牌”。 ASP.NET 4.6 已经支持在生产环境使用:http://get.asp.net

但是,命名是新的,完全截取自 ASP.NET 框架 —— “ASP.NET 5″,但这并不是个好主意,其中一个原因是:5 > 4.6,这样看起来 ASP.NET 5 比 ASP.NET 4.6 版本号更大,更好,甚至是可以替代 ASP.NET 4.6。

所以修改了名字,选择了一个更好的版本号。

重新引入 ASP.NET Core 1.0 和 .NET Core 1.0

  1. ASP.NET 5 现在是 ASP.NET Core 1.0.
  2. .NET Core 5 现在是 .NET Core 1.0.
  3. Entity Framework 7 现在是 Entity Framework Core 1.0 或者 EF Core 1.0

为什么是 1.0?因为他们全都是全新的。.NET Core 概念是新的, .NET Core 1.0 CLI 也是新的。不仅如此,.NET Core 不是完整的 .NET Framework 4.6。.NET 团队还在研究服务端图像库,也正在研究 ASP.NET 4.6 和 ASP.NET Core 1.0 之间的不同。

ASP.NET Core 1.0

那么如何选择?

非常明确的是,ASP.NET 4.6 是个更成熟的平台,经过了很好的测试。 ASP.NET Core 1.0 是 1.0 版本,包括 Web API 和 MVC,但是不包括 SignalR 或者 Web Pages。ASP.NET Core 1.0 不支持 VB 或者 F#。

ASP.NET Core 1.0 并不是结束,仅仅是个全新的开始, ASP.NET 4.6 还会继续更新,继续提供完整的支持。

.NET

快速将C#类型转成TypeScript介面定义

使用 TypeScript 处理 AJAX 请求时,常需要在前端定义与 C# 物件属性一致的 TypeScript 类型,以便将后端传来的 JSON 资料还原成强类型物件。针对较正式的资料模型,我会用 CodeGen 方式同步 C# 与 TypeScript 端的类型定义(顺便处理多语系问题)。但蛮多时候处理对象只是零散的小类型,不必杀鸡用牛刀,针对这类需求,推荐一个好用工具-TypeLITE。

在 NuGet 查关键字”typelite”,很快就可找到 TypeLite 套件。

66372-20160118172058390-650467009

安装后,项目会加入 TypeLite.dll、TypeLIte.Net4.dll,并在 Scripts 目录下新増 TypeLite.Net4.tt。接着就可以修改 TypeLite.Net4.tt 内容,决定为哪些类型产生 TypeScript 定义。

TypeLITE 预设做法是执行 .ForLoadedAssemblies ()自动寻找组件标注[TsClass] Attribute 的类型,但实务上用 .For<类型名称>()列举要转换的类型(如红框所示)比较方便;若类型来自网站项目以外的组件,记得要加上<#@ assembly #>宣告(如黄框所示)。

66372-20160118172327125-622267615

安装后,项目会加入 TypeLite.dll、TypeLIte.Net4.dll,并在 Scripts 目录下新増 TypeLite.Net4.tt。接着就可以修改 TypeLite.Net4.tt 内容,决定为哪些类型产生 TypeScript 定义。

 

TypeLITE 预设做法是执行 .ForLoadedAssemblies ()自动寻找组件标注[TsClass] Attribute 的类型,但实务上用 .For<类型名称>()列举要转换的类型(如红框所示)比较方便;若类型来自网站项目以外的组件,记得要加上<#@ assembly #>宣告(如黄框所示)。

66372-20160118172209843-629903048

TypeScript 定义档仅在开发编译阶段提供强类型约束及提示,不会产生任何 JavaScript,不用担心 TypeLite.Net4.d.ts 的内容太复杂。就这样,轻轻松松几个步骤,就把 C# 端的类型定义搬到 TypeScript 端~

微软发布了ASP.NET WebHooks预览版

微软近期发布了ASP.NET WebHooks的预览版,这是一个可用于创建及使用Webhook功能的库。WebHooks支持MVC 5及WebApi 2。

Webhook是一种通过HTTP实现用户自定义回调函数的模式。客户可以选择订阅某些类型的事件,并在这些事件实际发生时以POST请求的方式接 收这些事件。Webhook的一大要点在于它是使用HTTP实现的,这也意味着利用或实现这项技术无需任何新的基础设施的支持。

WebHookReceivers_3132734c-c730-475e-a3c9-1239b97b542d

ASP.NET WebHooks为Webhook的发送与接收操作提供了基础构建块。在接收端,它提供了一种通用的模型,用于接收并处理来自于Webhook提供者的事件。而在发送端,它则提供了对管理订阅与发送事件功能的支持。

InfoQ与来自微软ASP.NET团队的Henrik F Nielsen和Brady Gaster进行了一次访谈,以了解该项目更多的细节信息。

InfoQ:成立ASP.NET WebHooks这一项目的动机是什么?

ASP.NET WebHooks成立的动机有两方面

  1. WebHooks为HTTP服务的整合提供了一种协议模式,从而能够通过HTTP请求的形式建立一种非常简单的事件通知模型。通过对某个 Webhook的订阅,你就能够关注其他服务上的更新,并在更新时获得通知。这样一来,就有大量的整合场景成为可能。你将能够与其他的服务进行交互、在变 更时获得通知、并进行相应的操作。这种整合可以包括任何形式,例如在Dropbox中上传了某个新文件、在Trello中新建了一个Issue、或是通过 PayPal进行了一次支付操作。随着WebHooks的应用不断增多,这种应用场景也将产生指数级的增长。
  2. 虽说这一模式本身并不复杂,但还是有一些基本的规则需要处理。包括安全模型、数据格式、以及基于这一基本模式的各种变体。麻烦的地方在 于,目前大多数的Webhook提供者在处理这些基本规则时都存在着细微的差别。这种差别就像雪花一样,虽然每片雪花看起来都很相似,但多多少少存在着一 些特别之处。ASP.NET WebHooks的目的就是处理所有这些繁琐的部分,提供一个统一的用户模型,并让用户能够快速开始进行在服务间进行整合的任务

InfoQ:Webhook除了HTTP之外并没有其他任何确立的协议,那么在发送方是否会存在某些方面的限制因素?(作为接收者来说)ASP.NET WebHooks是否能够自动兼容那些目前已经提供Webhook的服务呢?

HN:我们已经在项目中提供了针对各种服务的Webhook,例如Azure
Alerts、BitBucket、Dropbox、GitHub、Kudu、Instagram、
MailChimp、PayPal、Pusher、Salesforce、Slack、Stripe、Trello,以及 WordPress,不过要添加对其他提供者的支持也是很简单的,并且所支持服务的名单还在不断地增长中。事实上,对于Kudu和BitBucket的支 持是来自于社区所提交的pull请求,我们也正在添加对更多的提供者的支持。

InfoQ:到WebHooks正式发布为止,它的路线图是怎样的?

HN:关于正式发布的计划,我们现在还没有什么正式的说法,不过我们很乐于倾听来自社区的反馈,并接受他们的贡献,包括pull请求和各种建议

BG:我们从社区中获得了一些反馈,他们希望能够对WebHook接收消息的功能进行调试,就像在本地进行调式一样。他们也欣赏远程调试的想法,但更愿意能够通过点击“F5”来启动他们的项目并发送Webhook。我们目前正在为某些想法设计原型,争取为Visual
Studio带来这一特性。

ASP.NET WebHooks是一个开源项目,托管在GitHub平台上。

Jexus 5.8.1 BETA1,全面支持ASP.NET5跨平台运行

作为一款运行于Linux/FreeBSD平台上以支持ASP.NET著称的高性能HTTP服务器和反向代理服务器,继5.6版完成对OWIN标准应用的支持后,就把着力点放到了对ASP.NET5的支持。

ASP.NET

但是,由于ASP.NET5与之前的ASP.NET相比,不管是从运行环境还是部署方式都发生了革命性的变化,Jexus很难像“前ASP.NET时代”那样,把ASP.NET5轻易地纳入其工作进程内直接运行。

支 持ASP.NET5,摆在Jexus面前有多种待选方案,比如利用OWIN协议针对ASP.NET5开发专用的适配器,或者利用Jexus的反向代理功 能,等等等等,但反复权衡之后,Jexus 5.8.1版选择了一条更加直捷且现实可行的方案:通过“端口转发”功能,把网站端口与应用程序宿主端口“桥接”起来。

之所以选择“端口转发”这个方案,是因为:
1,OWIN方案。由于mono与.NET Core是完全不同的两个运行平台,本质上有很大的不同,为在Jexus进程内运行的OWIN适配器的开发工作造成了极大的困难,而且ASP.NET5还在发展中,架构方面、API方面都有相当的不确定性;
2,反向代理方案。Jexus支持反向代理并且可以利用它做负载均衡,但是,反向代理由于需要对外部用户发过来的请求包和工作服务器发回来的响应包进行不 同程度的解析和重组,必然会消耗一定的计算资源。而且,反向代理对于WebSocket等技术的支持也有很大的难度和更大的性能消耗;
3,基于.NET Core重新改写Jexus。这个方案明显不现实:原因之一,Jexus必须继续支持已经在生产环境中被广泛使用的“前ASP.NET”,如果基于 core改写,就会出现与“前ASP.NET”兼容性问题甚至出现“断代”风险,这绝不是Jexus用户愿意看到的事;原因之二,Jexus已经是一个开 发了多年的成熟的WEB服务器,重写Jexus绝不是一个简单的事情,需要花费相当长的时间和非常大的精力。

“端口转发”有着类式端口“桥 接”的直接效果,它既避免OWIN方案的开发难度,也避免了反向代理方案在性能方面的耗损和应用层交互协议的局限性。而且更重要的是,这个方案在支持微软 为ASP.NET5量身打造的Kestrel这个宿主服务器的同时,也支持其它的花样繁多的自宿主应用,把Tomcat、node.js的服务让 Jeuxs整合起来对外统一用80端口提供服务,也完全是可行的。

Jexus 5.8.1 BETA1已经发布,感兴趣的朋友可以到 http://www.linuxdot.net/ 去下载。

程序员选择PHP还是ASP.NET

在执行一个网站或Web App的开发任务的时候,即使是最有经验的程序员也会有这样的困惑——如何选择编程语言。最常见的编程语言选择就是在PHP和ASP.NET之间。然而,PHP和ASP.NET都有庞大的使用群体,而且每个程序员对PHP和ASP.NET的意见均取决于他们的开发经验和偏好。所以,这样的选择可能会更多依赖于偏好。

ASP.NET
在这里没有一个明确的答案,但是本文将帮助你识别PHP和ASP.NET之间的区别,并根据你的喜好来做出选择,以便在开发项目里更顺利的完成任务。

平台和服务器绝对是两者之间的主要的差异所在,这一点是必须要意识到的。PHP是一种跨平台的服务器端的嵌入式脚本语言,完全可以自由的运行在Linux、UNIX、Mac OS或Windows上。另一方面,ASP.NET是一个面向对象,编译性的语言。你不能让PHP在一个Windows程序中运行,但是你可以拷贝ASP.NET的代码并把它放到WINFORM程序里面,而不用太大的修改。而且,ASP.NET受限于Windows平台。因此,它在这里实际上已经失去了开源的优势——低成本和高度支持的技术社区。
速度和性能
大多数程序员认为PHP和ASP.NET之间没有任何真正意义上的性能和速度之别。不过这是真的,只要你在较\
小的或更少的复杂项目上使用PHP和ASP.NET,就会发现它们之间的不同之处了。然而,如果是较大的Web App需要运行更多的大型程序的时候,在某种程度上编程语言是会影响速度的。其次,PHP和ASP.NET两者的选择还要考虑到任务的多样性。
以下举例说明:
 
从最简单的任务开始,App需要访问数据库,处理一个查询任务,并且通过服务器将处理结果传输到浏览器上。在这个过程里编程语言几乎没有对速度产生什么太大的影响/区别,但数据库服务器和查询程序可能会有一定的影响。
在Linux或UNIX上运行一个App能给你带来节省宝贵资源的优势,这些资源都是被GUI和额外的程序包消耗的,尤其是运行在Windows上的情况下。
当谈到通过访问文件系统来找到并发送图片到服务器的时候,PHP的表现效果可能会更好一些,但这都归功于Linux和ext4文件系统比Windows OS和NTFS优越。
 
开发、安装和部署
大多数用过这两种语言的有经验的程序员都会认同:在ASP.NET基础上开发项目需要花费更多的时\
间。原因在于它需要的代码行很多,其次在于,每一个代码在修饰过后还需要进行编译。
在安装和部署方面,由于ASP.NET在Windows OS里有很多特性,所以ASP.NET也提供了更多的缓存。然而,Linux已经跟上了ASP.NET的最新版本,在可用性方面做出了更合理的简化。
可扩展性
从上面的论述看来貌似是在提倡使用PHP,但是在可扩展性方面,ASP.NET才是真正的赢家。ASP.NET使用C#,因此可以提供更强大的面向对象的支持。
最后,选择PHP还是选择ASP.NET,这主要取决于你的技能、经验,当然还要考虑客户需求。理想情况是掌握这两种语言,不管使用哪一个都游刃有余的话,那是最好不过了。