ASP.NET MVC 2 RC 发布

18. 十二月 2009
ASP.NET MVC是既ASP.NET WebForms之后,微软推出的Front Controller式的Web开发模型,它弥补了前者对HTML控制能力不足,单元测试较为困难等缺点。更重要的是,ASP.NET MVC基于MS-PL发布,是一个真正的开源框架——且没有任何平台限制,也就是说,您可以在mono下使用或开发ASP.NET MVC的相关项目。

其实微软在今年3月的MIX大会上发布ASP.NET MVC RTM的时候,就已经公布了部分ASP.NET MVC 2的计划,并且在官方代码源中包含的MvcFutures项目中实现了V2的部分功能雏形。在沉寂了4个多月之后,现在微软终于发布了ASP.NET MVC 2的Preview 1版本,并在论坛中向社区征求反馈意见和建议。令人放心的是,ASP.NET MVC 2 Preview 1能够与ASP.NET MVC 1.0 RTM共存,不会影响后者的正常使用。

下载:ASP.NET MVC 2 RC

.NET技术, 业界动态 ,

10个鲜为人知的C#关键字

16. 十二月 2009

yield

yield关键字会告诉编译器当前的函数是在一个循环内部,编译器会相应生成一个执行它在循环体内部所表示行为的类,yield和return关键字一起用于为枚举器对象提供返回值,比如说:在foreach内部的每一次循环内,yield关键字用于终止当前循环:

public classList{    //using System.Collections;    public static IEnumerable Power(int number, int exponent)    {       int counter = 0;       int result = 1;       while(counter++ < exponent)       {          result = result * number;          yield return result;        }    }    static void Main()    {        // Display powers of 2 up to the exponent 8:        foreach (int i in Power(2, 8))        {            Console.Write("{0} ", i);        }    }}    /*    Output:    2 4 8 16 32 64 128 256    */

MSDN链接:http://msdn.microsoft.com/en-us/library/9k7k7cf0.aspx

var

自从C# 3.0开始,在函数作用局范围内声明的变量可以通过var关键字声明成隐含类型,隐含类型是强类型,你需要自己声明隐含类型本地变量,然后编译器会帮你决定为某种强类型。

在2.0版本上跑的程序也可以使用var关键字,但是需要你的编译器是3.0以上版本并且设置代码输出版本为2.0:

var i = 10; // implicitly typedint i = 10; //explicitly typed

MSDN链接:http://msdn.microsoft.com/en-us/library/bb383973.aspx

using()

定义一个范围,在范围外的对象将会被回收:

using (C c = new C()){c.UseLimitedResource();}

MSDN链接:http://msdn.microsoft.com/en-us/library/yh598w02%28VS.80%29.aspx

readonly

readonly关键字是一个可作用在变量域上的修饰符,当一个变量域被readonly修饰后,这个变量只可在声明或者当前变量所属类的构造器内赋值。

MSDN链接:http://msdn.microsoft.com/en-us/library/acdd6hb7%28VS.80%29.aspx

as

as操作符很像一个类型转换器,然和,当转换无法发生时(译者按:比如类型不匹配),as会返回null而不是抛出一个异常:

class Class1{ }classClass2{ }classClass3: Class2{ }classIsTest{  static voidTest(objecto)  {     Class 1a;     Class 2b;     if(o isClass1)     {         Console.WriteLine("o is Class1");         a = (Class1)o;                // Do something with "a."     }     else if (o is Class2)     {         Console.WriteLine("o is Class2");          b = (Class2)o;                // Do something with "b."      }     else     {         Console.WriteLine("o is neither Class1 nor Class2.");     }  }  static void Main()  {     Class1 c1 = new Class1();     Class2 c2 = new Class2();     Class3 c3 = new Class3();     Test(c1);     Test(c2);     Test(c3);     Test("a string");  }}    /*    Output:    o is Class1    o is Class2    o is Class2    o is neither Class1 nor Class2.    */

MSDN链接:http://msdn.microsoft.com/en-us/library/scekt9xw.aspx

default

在泛型类和泛型方法中产生的一个问题是,在预先未知以下情况时,如何将默认值分配给参数化类型 T:

  • T 是引用类型还是值类型。

  • 如果 T 为值类型,则它是数值还是结构。

给定参数化类型 T 的一个变量 t,只有当 T 为引用类型时,语句 t = null 才有效;只有当 T 为数值类型而不是结构时,语句 t = 0 才能正常使用。解决方案是使用 default 关键字,此关键字对于引用类型会返回 null,对于数值类型会返回零。对于结构,此关键字将返回初始化为零或 null 的每个结构成员,具体取决于这些结构是值类型还是引用类型:

T temp = default(T);

MSDN链接:http://msdn.microsoft.com/en-us/library/xwth0h0d.aspx

global

在  ::运算符前面使用的 global 上下文关键字引用全局命名空间,该命名空间是任何 C# 程序的默认命名空间,未以其他方式命名。

class TestClass : global::TestApp { }

MSDN链接:http://msdn.microsoft.com/en-us/library/cc713620.aspx

volatile

volatile 关键字表示字段可能被多个并发执行线程修改。声明为volatile 的字段不受编译器优化(假定由单个线程访问)的限制。这样可以确保该字段在任何时间呈现的都是最新的值。

MSDN链接:http://msdn.microsoft.com/en-us/library/x13ttww7%28VS.80%29.aspx

extern alias

有时可能有必要引用具有相同完全限定类型名的程序集的两个版本,例如当需要在同一应用程序中使用程序集的两个或更多的版本时。通过使用外部程序集别名,来自每个程序集的命名空间可以在由别名命名的根级别命名空间内包装,从而可在同一文件中使用。

若要引用两个具有相同完全限定类型名的程序集,必须在命令行上指定别名,如下所示:

/r:GridV1=grid.dll

/r:GridV2=grid20.dll

这将创建外部别名 GridV1 和 GridV2。若要从程序中使用这些别名,请使用 extern 关键字引用它们。例如:

extern alias GridV1;

extern alias GridV2;

每一个外部别名声明都引入一个额外的根级别命名空间,它与全局命名空间平行,而不是在全局命名空间内。因此,来自每个程序集的类型就可以通过各自的、根源于适当的名空间别名的完全限定名来引用,而不会产生多义性。

在上面的示例中,GridV1::Grid 是来自 grid.dll 的网格控件,而 GridV2::Grid 是来自 grid20.dll 的网格控件。

MSDN链接:http://msdn.microsoft.com/en-us/library/ms173212%28VS.80%29.aspx

原文链接:http://hatim.indexdev.net/2009/12/08/10-not-so-well-known-keywords-in-c/

.NET技术

WPF与Silverlight的关键区别?

18. 十一月 2009

当WPF和Silverlight越来越受到.NET开发人员重视的时候,两者间的界限也越来越模糊。回顾六月,Wintellect发布了鲜为人知但极其重要的“微软WPF和Silverlight之异同白皮书”。我们建议GUI开发人员要通读全部69页,我们会列出主要的观点及其对相关业务范围开发人员的影响。

依赖关系属性是两个平台的重要组成部分,使用PropertyMetadata可代替普通字段来保存属性。Silverlight仅提供了该类,而WPF却有若干子类型可用。

  • UIPropertyMetadata添加了一个标识符,用于决定“在使用了元数据实例的地方,是否应该禁播依赖关系属性的动画”
  • FrameworkPropertyMetadata添加一个标识符来指示影响管道的那些属性,包括控制管理、测量和呈现。它也可用于指示属性是否允许数据绑定以及默认的类型。由于Silverlight不支持该类,因此所有的数据绑定在默认情况下都是单向的。

Silverlight不支持隧道事件。两个平台都支持Direct事件和Bubbling事件。

WPF支持多种类型的触发器。一个简单的触发器附加到依赖关系属性后,当触发器条件满足的时候便会自动修改样式。除了简单触发器以外,WPF也支持可响应路由事件或使用数据绑定的触发器。

Silverlight使用视觉状态管理器代替触发器。WPF当前并不提供该技术,但会在WPF 4.0中添加。

Silverlight仅支持若干标记扩展。除了通用的StaticResource、Binding和TemplateBinding扩展以外,WPF还添加了DynamicResource、RelativeSource、x:Type、x:Static和x:Array。

有很多键盘和鼠标事件仅在WPF中可用。由于为数众多的关系,我们稍后会列出完整列表。

关于UIElement类和IInputElement接口。当某个控件被禁用的时候,WPF使用它们来禁用所有的子控件。Silverlight不提供这种功能,所以开发人员不得不手动遍历控件树。

在通信方面,Silverlight仅限于BasicHttpBinding和PollingDuplexHttpBinding。当然,WPF支持所有的绑定。

最后,打印功能在两者之间也完全不同。WPF可直接打印可视化树而Silverlight则依赖浏览器实现。

.NET技术 ,

Mono发布了面向Visual Studio的工具包

12. 十一月 2009

Mono最近发布了一套名为Mono Tools for Visual Studio(下称Mono Tools)的工具包,目的是辅助开发人员在Visual Studio下开发跨平台的.NET应用程序。在Mono Tools的帮助下,开发人员可以利用自己熟悉的开发环境,工具,代码或类库进行工作,面向Linux操作系统构建,调试和部署.NET应用程序。

Mono Tools的功能主要有以下几部分:

  • 将应用程序部署至Linux:可以从Visual Studio中向运行着Mono的Linux系统中部署软件。Mono Tools利用UPnP来检测本地网络上的Linux机器,或根据开发人员指定的IP决定部署的目标。
  • 从VS中直接运行mono程序:Mono Tools允许开发人员在远程Linux系统上,或者直接在Windows中以Mono平台运行程序。这样开发人员便可以更方便的观察程序在不同平台上的表现。
  • 在VS中调试远程Linux系统中的程序:开发人员经常抱怨Linux系统下的调试工作非常麻烦,Mono Tools现在允许开发人员使用Visual Studio原有的方式(如本地变量、察看、断点及单步)调试远程Linux系统中的mono应用程序。
  • 构建Linux系统的软件包:Mono Tools让开发人员可以在Vistual Studio中生成Linux的安装格式,只要在解决方案中进行配置和发布便可得到Linux环境中可用的RPM包。
  • 发布为Linux设备(Appliance):利用Mono Tools,开发人员可以直接将一个Mono应用程序发布并上传至SUSE Studio,以便生成一个易于分发和部署的Linux设备

Mono Tools面向不同客户提供了专业版、企业版和终极版三种授权方式,您也可以下载并进行30天的试用。有关mono的更多信息请关注Mono的官方网站InfoQ的内容

.NET技术 , ,

WPF 4.0为我们带来了新特性

12. 十一月 2009

之前来自WPF Toolkit的3个控件现在移到核心发布库中。具体是,DataGrid、DatePicker和Calendar 控件。它们也具有Silverlight相应的版本,微软承诺在WPF和Silverlight中的版本“99%的API和行为都兼容”。DataGrid特别重要,由于缺乏这个东西,WPF经常被提到不适合于业务处理应用程序。

在4.0发布之后,还计划发布两个扩展包,每一个都包含了额外的控件。“锦囊”将包含AnimatingTilePanel、ColorPicker、InfoTextBox、ListPager、NumericUpDown、Reveal、TransitionsPresenter和TreeMapPanel。另外一个是WPF Ribbon Control,它目前处于CTP阶段。

在图形方法,对Pixel Shader 3.0的支持已经加入。以前的WPF只能藉由ShaderEffect支持Pixel Shader 2.0。对于开发人员,也许更重要的是LayoutRounding。它将强制布局引擎把元素放到整个像素边界。当前的控件只能排到子像素边界上,这会导致模糊的界面。

说起模糊的界面,WPF知名的文本渲染问题也被解决了。为了搞定这个问题,老的文本渲染代码被完全代替。随着而来的还有几个文本格式选项,可以实现某种程度的微调。

Windows 7获得了极大的关注。WPF 4.0将提供对多点触摸、JumpList和任务栏集成的支持。缩略图工具栏特别有意思。即使在应用程序最小化的情况下,也可以让用户与之交互。

在数据绑定前端,添加了绑定到实现IDynamicMetaObjectProvider接口的动态对象的支持。这囊括了所有基于DLR的语言,如IronRuby和IronPython。

来自于Silverlight的可视化状态管理器(Visual State Manager)特性也进入了WPF的世界。WPF已经具有了无比强大的触发器功能,不过它比起Silverlight的可视化状态管理器难用的多。

.NET技术 ,

.NET和Mono项目版Git-Git#

20. 十月 2009

Git#是由JGit移植到C#的一款流行的.NET和Mono版本源代码管理系统Git。其它类似的项目还有msysgitgitextensions

Git#意在“完全兼容原始git,并可以当作一款把git作为对象数据库的应用程序的轻量级程序库,它能以某种方式读取或操作数据字典”。

Git#的最新版本代号为Alpha 0.1.3,仍然采用命令行接口,但它提供稳定的代码库,可从.NET项目访问Git数据字典。相应的API仍会改动。

Git#已经为有兴趣参与并更多了解项目的人们设立了讨论组。GitHub站点提供了可直接使用的演示程序。还有一些示例介绍Git#入门。该项目和JGit的一样使用BSD许可

msysgit是一款Windows的Git提供程序,比起Git#更加成熟和完善,但Git#作者却说“它不易于扩展和嵌入到其他应用程序当中”。该程序使用的是GNU GPL v2许可。

还有另一个项目叫gitextensions它提供多个工具来帮助程序员在Windows下使用Git。它集成Windows浏览器和VS 2005/2008插件。为GNU GPL v3许可。

.NET技术 ,

Visual Studio 2010 Beta 2即将发布

20. 十月 2009
最新消息,Visual Studio 2010 Beta 2已经可以下载了。这绝对是微软开发者翘首以盼的版本,目前,下载仅对MSDN订阅者开放。 预计在10月21日,微软将发布此版本。正式版本将在明年3月公布,开发者们不用等太久了!

.NET技术, 业界动态 ,

ASP.NET MVC 2预览版更新

9. 十月 2009

微软发布了新的ASP.NET MVC 2预览版。Preview 2在之前的基础上增加了客户端验证,精简的Area支持,以及抽象的数据标记(Data Annotations)验证和元数据提供者等功能。

ASP.NET MVC 2包含了jQuery验证类库,根据模型的元数据来提供客户端验证功能。在Preview 2中还可以编写一个适配器来沟通客户端类库和JSON元数据(类似于xVal validation框架的做法),这样便可以在项目中使用另一种客户端验证类库了。

在Preview 1中提出了一个重要的概念:Area。Area提供了一个方法将一个大型Web应用程序划分为不同的项目。Preview 2简化了这个功能,如今已经可以在单个项目中使用Area进行组织了。

Preview 2还提供了Model Validation Provider和Metadata Provider。这些提供者允许我们为模型添加额外的验证逻辑,以及其他一些元数据的提供方式。默认的提供者使用了数据标记,这是在Preview 1中引入的验证和元数据表现方式。

据MVC团队的高级程序经理Phil Haack所述

... 从Preview 1中你可以发现这样的主题:我们尝试直接使用数据标记,而在Preview 2中我们提出了一个抽象层,这样就可以为验证和元数据提供者引入自定义实现了。

例如,你可以使用企业库的验证模块来替换默认的验证方式。此外,也只要少量工作便可以将模型的元数据存放在另外的地方,而不是属性中。

ASP.NET MVC 2 Preview 2可以与MVC 1共存,但是在安装MVC 2 Preview 2之前必须先卸载Preivew 1版本。在VS 2008中,两者会表现为不同的项目类型。如果你希望在VS 2010中使用MVC 2则需要等待Beta 2的发布,其中会直接包含MVC 2。

查看英文原文:ASP.NET MVC 2 Preview Updated

.NET技术 ,

ASP.NET vs. PHP,哪个更快?

16. 九月 2009

上个月Joe Stagner在博客上发表了一系列文章比较了PHP和ASP.NET的执行性能,引起了来自双方程序员的大量回应。Joe表示,他会将这样的测试持续下去,并寻求更为合适的方式,以获得对实际项目来说尽可能有参考价值的结论。

Joe表示:

一般来说,作性能测试的目的是要尝试证明一方比令一方要快。我受雇于微软,同时编写PHP和ASP.NET代码。我在.NET出现之前就在使用PHP,两个东西我都很喜欢。

所以,我很难说出哪个更好。当我说PHP好话时,我的微软同事们会写信来批评我,而当我发表倾向于ASP.NET的言论时,我的PHP朋友们会说我是微软的托。

我进行这个测试是因为每个人都对PHP的性能有自己的看法(Windows vs. Linux & 5.2 vs. 5.3),却没人能给出明确的数据。

根据Joe的描述,测试环境如下:

  • 所有的测试都在同一台机器上运行(拥有4G内存和60G 7200转硬盘的Toshiba Tecra M5)。
  • Ubuntu 9和Windows Server 2008标准版分别安装于独立(但相同)的硬盘中。
  • Linux使用Apache2,Windows使用IIS 7作为各自的Web服务器。
  • 双方的操作系统都进行了完整的patch或升级。
  • 双方的系统和运行时都没有进行额外的性能增强。

实验结果上看,PHP在Linux和Windows的执行性能各有千秋:

  • 纯粹的语句执行在Windows上表现更好。
  • 函数调用在Windows上更快。
  • 对象的创建和访问,对于PHP 5.2来说在Linux上更快,但是对于PHP 5.3来说则是Windows更快。
  • 类库调用在Linux上快得多(如在Ubuntu上进行加密要比Windows要快3到5倍)。
  • 在Linux上访问文件性能略高于Windows,不过Windows上文件复制的性能要比Linux慢60%,可能是ACL高级安全的缘故。
  • 在Linux上访问MySQL要比Windows快不少,而且在Windows上运行PHP 5.3的情况则更为恶劣(不过从下面PostgreSQL的情况上来看,这应该是糟糕实现的缘故)。
  • PostgreSQL在两个平台上的性能非常接近(1000个操作的差距在0.06秒之内)——无论是PHP 5.3还是PHP 5.2,Windows上表现都略胜一筹。
  • Windows上PHP 5.2访问MS SQL Server的性能稍逊于在Linux上访问MySQL(此时还没有面向PHP 5.3的SQL Server支持)。

Joe认为,这表示:

  • 我们可以这么认为,对于纯粹的PHP执行性能来说,Linux和Windows相差无几,这不会成为选择Linux或Windows作为部署平台的决定性因素。
  • 如果你在构建一个应用程序,那么PostgreSQL可能是更好的选择。因为它在两个平台上的表现都很优秀。
  • 如果你的应用程序必须使用MySQL,那么选择Windows就需要早些计划扩展性问题了(个人认为Sun不太可能为Windows优化MySQL的性能)。
  • PHP的第一个版本的SQL Server驱动程序要比MySQL或PostpreSQL要慢一些,但这应该不会成为问题。第二个版本的驱动器正在开发之中,它会带来性能提升。

在Joe看来,全面来看,PHP和IIS团队在执行性能上已经做的非常成功,接下来就需要各开源程序的团队(Drupal、WordPress、Joomla等等)为各平台进行性能优化了。

不过,除了文件复制操作之外,ASP.NET在性能方面全面领先于PHP(无论部署在Linux还是Windows上面):

  • Linux上访问MySQL的性能稍稍优于Windows上访问SQL Server的性能(使用普通的数据类型和SELECT语句)。但是这里的差距几乎可以忽略不计。
  • ASP.NET(C#)操作,如对象使用,类库调用等等,其性能都远高于PHP。

对于这个测试结果,Joe补充道:

我知道我的一些PHP朋友和Linux伙计们要跳出来驳斥我的测试和结果了。:)

我一直在思考,这样的性能比较是否需要加入一些高级的优化选项。不过.NET方面也有例如多线程,异步请求,和各种缓存方式可以使用

请注意——我并没有说“ASP.NET更快,所以你不应该使用PHP!”,我使用认为,PHP过于简单导致对某些高级应用来说有些举步维艰,就像ASP.NET在项目早期会有学习方面的复杂性。

对我来说,PHP最令人兴奋的地方不是它的语言/平台,而是成千上万聪明的PHP开发人员,以及各种优秀的项目(如Drupal、Joomla、WordPress、PHPBB、Nuke等等)。

可以这么认为,PHP在Windows和Linux上的性能处于同一个水平上,我现在终于可以为Windows编写那些我盼望着许多年的PHP类库了。

Joe还公开了测试代码。他表示,如果你对这个测试的结果有疑义,可以亲自进行这个实验,或是编写你自己的测试代码进行试验。

文章发布之后,许多网友对这一测试结果发表了看法。Joe基本上逐一回复了其中的主要观点

“我使用ASP.NET只是因为我喜欢Visual Studio IDE”——我个人认为Visual Studio是最有生产力的开发工具。但是,PHP的有不错的选择。我使用Zend Studio,PHPEd,Komodo,Delphi for PHP,这些都很不错。我讨厌Eclipse,不过Zend也在这方面为PHP开发做了不少扩展。

应该比较ASP的性能——不用了,谢谢。旧式的ASP与目前的PHP与ASP.NET差距太大了。做这种比较,似乎是在建议使用ASP开发新项目,我强烈不建议你这么做。

32位与64位系统之间的比较——这些测试的目的并不是为了体现64位系统上的性能差距。今后的测试我会增加64位的场景。

“PHP丑陋至极”——哦,我不同意。旧式ASP要丑陋多了。你可以写出非常可怕而丑陋的PHP代码,也可以写出丑陋而可怕的C#或VB代码。同样,你也可以写出优雅的C++样式的PHP。这完全只和开发人员的技能有关。

应该使用Windows上的Apache进行测试——Apache是Linux上的服务器,不过我认为如果你在Windows上不使用IIS 7则会损失太多太多东西了。

“有办法在Win2K8中,在不损失安全性的前提下加快文件复制性能吗?”——似乎不行。我认为这涉及到Windows服务器上的ACL系统。我以后可能会测试通过数据流读取文件的性能,有些东西的性能可能会有所改善。不过,Web应用程序一般不会编程来复制大量文件。

“PHP一直是,也永远只是一个半专业性质的环境”——这种说法狗屁不通。PHP平台上有许多专业的,高质量的应用程序,也有很多我非常尊敬的开发人员。是否专业是开发人员的问题,不是PHP或ASP.NET的问题。

“我认为比较没有opcode缓存的PHP很不公平,.NET是编译执行的,而PHP需要每次都解释并‘编译’页面”——我同意这个测试可能不够完整,但是我不认同这个逻辑。我测试PHP的方式,就和下载安装的方式一样。我的虚拟主机也没有安装op-code缓存。而事实上,ASP.NET自带这个特性也并不意味着测试是不公平的,这是因为PHP缺少这个特性——不过这个要求很合理,我正在准备新的测试。

“说PHP不是一个‘专业的’语言很没道理,因为几乎所有最大的站点都是用PHP构建的”——这种说法是没道理,不过说那些站点“几乎都是”用PHP构建的也是错误的。有些是,有些不是。

Joe补充道:

如果你们看到这一数据之后对ASP.NET信心倍增我自然很高兴。如果我不认为.NET是开发Web应用程序来说是一种更好的选择——至少不属于其它平台,那么我也不会在微软工作了。

但是……如果你因为这些数据而忽视PHP,也是错误且幼稚的行为。

从纯技术角度来说,我认为.NET远比PHP强大,但这并不意味着PHP不够强大。在我看来,PHP的力量体现在众多的应用程序以及可用的框架。

大约一周以后,Joe公开了第二次测试的结果。与前一个测试相比,第二个测试主要有以下两个改变:

  1. 为Linux和Windows上安装了op-code缓存,并重新运行了大部分测试。
  2. 由于一些依赖项的问题,PHP 5.3 + APC的测试平台变成了Debain 5操作系统。

对于第二次测试及其结果,Joe解释到:

从结果上看,Ubuntu和Debian上运行PHP的性能差距可以忽略不计。部分条目的性能有些细小的改进,有些则有25%的提高,但是总体来说其效果比我想象中要来得低。

使用APC之后,一些条目的运行反而变慢了,不过我认为这只是机器所造成的误差。请注意,表格中显示的不是第一次的结果,都是经过两次刷新,确认是在缓存命中时得到的结果。

我认为现在的测试非常公平。

空的循环测试和空的函数执行非常重要,因为这反映了语言或平台的基础消耗。这是处页面传输等性能开销外的性能消耗,是一个重要的考虑方面。

我的一些PHP朋友也认可这个测试的准确性,不过给出了非常有见解的补充:

  • ASP.NET在性能上的领先不会对我有什么影响。PHP是我的最爱,我的应用程序已经足够快了。
  • 没错,ASP.NET在基础性能上是比较快,但是我的应用程序可以通过优秀的页面实现和JavaScript实践把这部分性能补回来。
  • 我在进行Drupal开发,我对PHP最熟悉,因此我宁愿多花一些硬件来保持更好的开发效率。

这些都是很不错的评论!

此外,根据上一次实验的结果,在Windows平台上运行PHP时,在MySQL和文件的访问上有一些性能问题,微软许多团队都向我获取了相关信息。希望这些数据都够转变为切实的改进。

Joe表示,他将收集大家认为更公平,更有意义的测试场景。以下是他所计划的测试项目:

  • 实际页面测试:循环,寒暑调用和对象操作是一类测试,不过页面的整体呈现则是另一种有意义的测试。
  • 负载测试:哪一个环境可以同时处理更大量的请求。
  • 在负载测试中,哪一方的性能会下降地更快。
  • 在各种情况下,64位平台的表现如何。

国内也曾经进行过PHP在Linux和Windows平台上的性能测试。InfoQ曾经报道过微软在WordCamp China 2009大会上公开了之前与康盛创想合作进行的性能评估结果:在Windows Server 2008 + IIS上运行PHP,从平均相应时间,每秒处理的请求数,以及数据吞吐量等多方便均优于Linux + Apache的托管方式。

.NET技术 ,

.NETZ—.NET函数库的压缩和打包工具

14. 九月 2009

从一开始,.NET运行时所提供的正统打包系统就是程序集集合的方式。这虽然比松散的脚本文件或类文件集合的方式好很多,却没有静态连接执行文件或可执行的JARs那样方便。Vasian Cepa的.NETZ为广大的开发人员带来了压缩.NET程序集和打包到单一执行文件的功能。

默认情况下,.NETZ支持用#ZipLib或.NET 2.0的IO.Compression.DeflateStream来进行压缩。如果有必要,可以创建额外的压缩提供器。理论上,新的压缩提供器也能包含加密功能,不过类似的提供器还没有直接内置。

它也存在一些限制。在.NET 2.0项目中,不能支持本地化资源DLL。不像1.0和1.1,.NET 2.0不会触发AssemblyResolve和ResourceResolve事件以动态地解压缩程序集。不过,也有变通的方法的。

这个系统的另外一个限制是,不支持原生DLL或由托管C++创建的DLL。对于后者,是由于“托管C++编译器以一种不被.NET通用程序集载入程序所理解的方式,优化PE文件和IL元数据”。

查看英文原文:.NETZ – Compression and Packing for .NET Libraries

.NET技术

Windows 7 API Code Pack for .NET介绍

13. 八月 2009

“Windows API Code Pack for Microsoft .NET Framework”是一个API的包装,向.NET开发人员暴露了Windows的功能。这个代码包主要用C#写成,在暴露DirectX功能的时候也用到C++/CLI。可以看到源代码,不过它不是开源的。

虽然这个函数库的某些部分可以用于之前的操作系统,但它还是主要面向Windows 7开发人员的。下面的特性列表直接摘录自项目主页

  • Windows 7 任务栏的个性化快捷菜单(Jump List)、程序图标轮廓效果(Icon Overlay)、程序图标进度条效果(Progress Bar)、标签式缩略图(Tabbed Thumbnail)和缩略图工具栏(Thumbnail Toolbar)。
  • Windows 7 资源库(Libraries)、固定名称文件夹(Known Folders)、非文件系统容器。
  • Windows Shell的搜索API支持,提供了一个层级式的Shell命名空间实体、以及针对Shell对象的拖拽功能。
  • 资源管理器浏览器控件(Explorer Browser Control)。
  • Shell属性系统。
  • Windows Vista和Windows 7的通用文件对话框,并包括了自定义控件。
  • Windows Vista和Windows 7的任务对话框。
  • 包装了Direct3D 11.0、Direct3D 10.1/10.0、DXGI 1.0/1.1、Direct2D 1.0、DirectWrite、Windows图像组件(WIC)API。(DirectWrite和WIC是部分支持的)
  • 传感器平台API。
  • 电源管理API。
  • 应用程序重启核恢复API。
  • 网络列表管理器API。
  • 命令连接(Command Link)控件和系统定义的Shell图标。

查看英文原文:Introducing the Windows 7 API Code Pack for .NET

.NET技术, 计算机技术 ,

SQLite移植到了.NET

11. 八月 2009

Noah Hart将SQLite3移植到了C#上。虽然此次移植版本比原始版本要慢,但是此项目可以让.NET托管项目在不使用任何P/Invoke和不安全代码的情况下使用SQLite。

C#-SQLite被寄放在Google Code上,是从SQLite 3.6.16到C#的完全移植,代码版权使用MIT License。C#-SQLite通过了超过3万个测试用例,只有9个没有通过。编译好的二进制exe文件只有528KB,和原始版本的506KB差不多。性能方面要比原始的C版本差一些,但是Hart说他还没有对代码做任何性能优化,而且他认为目前的性能还可以接受。所有的数据单位都是行/秒:

Test C#-SQLite SQLite
Insert 300K 1300K
Select 1500K 8450K
Update 60K 300K
Delete 250K 700K

Cory Nelson解释了为什么移植SQLite要比其它方式更好:避免P/Invoke带来的“速度超慢和无法移植”问题。而且C代码“充斥着goto语句,会使优化变得十分困难”。

很多产品-如Adobe AIR-都包含和使用了SQLite。或许C#-SQLite最能发挥的地方是Silverlight项目,Tim Anderson指出

可以在微软Silverlight中作为本地数据库使用,保存在isolated storage中。

……Silverlight不允许P/Invoke和不安全代码,由于原始版本的SQLite中使用了大量的指针,即使只有很少的P/Invoke,不安全的代码却一定有很多。

虽然Silverlight是实现在.NET Framework上的,却不包含System.Data命名空间,但包含了System.Linq。

C#-SQLite并不是SQLite的官方版本,Hart也与SQLite.org没有任何关系。SQLite的创造者和商标所有人Richard Hipp,在一开始并不同意将“SQLite”包含在项目名中,但是后来同意使用C#-SQLite。

除了这个项目,还有其它一些托管数据库,比如:Perstdb4oSilverlight DatabaseSystem.Data.SQLite

查看英文原文:SQLite Has Been Ported to .NET

.NET技术 ,