wordpress建立的网站,望城警务督察网站建设,网站做多久流量,建网站用什么程序好显然Microsoft开发人员和管理人员并没有表达清楚#xff0c;事实上ASP.NET Core 2.0将会得到整个.NET Framework的支持。当前的更改只实现了在ASP.NET上提供.NET Core#xff0c;这是为了便于开发而采取的一个临时步骤。对此#xff0c;在ASP.NET Core预览发行声明中给出了如…显然Microsoft开发人员和管理人员并没有表达清楚事实上ASP.NET Core 2.0将会得到整个.NET Framework的支持。当前的更改只实现了在ASP.NET上提供.NET Core这是为了便于开发而采取的一个临时步骤。对此在ASP.NET Core预览发行声明中给出了如下的解释
在发布ASP.NET Core 2.0预览版时仅提供了对.NET Core 2.0 SDK的支持。我们的目标是在.NET Standard 2.0中发布ASP.NET Core 2.0使应用可运行在.NET Core、Mono和.NET Framework上。团队正致力于在Build大会之前解决最后一些问题最突出的问题是在ASP.NET Core 2.0预览版中使用了.NET Standard 2.0之外的API这妨碍了在.NET Framework上的运行。由于这些问题我们限制了Preview 1版本对.NET Core的支持以免对开发人员在.NET Framework上将ASP.NET Core 1.x应用升级到ASP.NET Core 2预览版时造成破坏。
在Register的一次采访中Miguel de Icaza确认了Microsoft对.NET Framework的承诺
我要对此做出澄清。我感到十分遗憾的是即将推出的.NET Core 2.0是我们专为Build大会准备它只是一个预览版因为我们发现其中存在一系列在.NET Framework上无法很快得到解决的问题。因此我们推出的软件包仅支持在.NET Core 2.0上运行ASP.NET Core 2.0。我们将会修复这个问题.NET Core 2.0终将运行在.NET Framework上。
即便是临时性更改一个依然需要解决的问题是要想进一步改进ASP.NET的性能需要提供更好的字符串处理库。
内存分配上的考虑
在.NET中几乎所有的字符串处理方法都要做内存分配该问题长期以来一直为人所诟病。在解析JSON、XML等格式时substring方法常会产生成百上千的微小字符串分配。这不仅耗费了大量时间生成拷贝而且对垃圾回收造成了很大的压力。这并非应用开发人员所能掌控的。
这种做法有其合理性。与.NET一样在Java中字符串也是不可变的。而Java自带的substring方法并不分配新的字符串它创建一个指向原始字符串的指针。虽然Java的substring方法无需分配内存但是存在着内存泄漏的风险。一个字符串substring方法可以保留5MB字符串不被垃圾回收这个问题相当恶劣因此在Java 1.7u6版中做了更改substring方法做内存分配。
在“SpanT建议”中开发人员可以选择使用两种不同的substring方法即分配内存的方法和不做内存分配的方法。ASP.NET Core所使用的解析库也可以被覆写在内部使用不分配内存的substring方法。但在解析操作的最后阶段需要确保释放所有Spanchar的实例。
这一更改还需要重新实现更高效的基本类型解析方法例如Int32.Parse和Inta32.TryParse等。理想情况下这些方法将会加入到基类库BCLBase Class Library中而不是以单独库的方式提供。这就回到了.NET Framework、Standard和Core的对比问题上。
毫无疑问可以加快对.NET Core的更改过程。除了操作系统特定的功能新特性将做优先更改。否则只有得到所有.NET/Mono的各种实体incarnation支持的新特性才会出现在.NET Standard中。虽然从理论上讲这些实体也归属于Microsoft的但是新特性的添加依然会是一个冗长的过程。
因此在开发ASP.NET Core的过程中基于ASP.NET进行构建是合乎情理的。这使得新的API在提交标准化前得到真实用例的精炼。
默认编码上的考虑
并非所有开发人员都了解在.NET内部使用的是UTF16字符串。除了实现文件或网络I/O处理之外对于大部分用例开发人员都无需考虑编码问题。
Web应用主要基于UTF8编码。同样在处理大部分用例时服务器端开发人员也无需考虑编码问题。只需确保无论使用何种内部格式最终都会转换为UTF8编码。
当需考虑性能时这种做法就存在问题。所有的Web请求最初都是以UTF8编码的需要在被.NET理解前转化为UTF16编码。反之所有来自.NET服务器的响应需要由UTF16编码转化为UTF8编码。
现在已有一些建议方法意在消除这种转换的必要。一种做法创建了Utf8String类并匹配字符串处理库之后就可以新建直接操作类的解析库。这一做法是完全“明确征得同意”Opt In的因此风险很低。
更全面的建议是由Matt Warren提出的称为“紧凑字符串Compact String实现”。该建议受到了OpenJDK中类似建议的启发它会在字符串中添加一个类型字段用于指示所使用的编码。这是一种更大程度上的更改对SpanT存在一些负面影响。
原文地址http://www.infoq.com/cn/news/2017/05/ASPNET-Core-2b .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
