本来CodeGear已经发布了Delphi 2007和C++Builder 2007，照理说这个仅仅添加了Delphi for .NET的新东西——RAD Studio 2007应该不会带来太多的新特性，但是仔细梳理一下，还是可以看出CodeGear公司不像Borland那样只想着赚大钱。CodeGear的用户可以得到的现实好处还是很多的。
升级策略
首先，来介绍一下CodeGear的产品升级策略。之前的Borland模式大家相信也比较熟悉，简而言之就是Update有限。如果你需要修正更多bug的机会，请购买下一代的产品。当然，这也意味着Update不会带来新的特性。
虽然在Delphi 2005和Delphi 2006的时候这一策略有所松动，但是直到CodeGear成立，我们才有机会看到现在的新局面——Update也可以包含新的特性！当你将Delphi 2007和C++Builder 2007升级到Update 3，你的IDE立刻就开始支持AutoSave/AutoRecover了，而且又多出了BlackFish SQL这个小巧好用的数据库。这可都是RAD Studio 2007才加入的新东西呀！假如你还没有升级到Update 3，赶快行动吧！
Delphi for .NET的策略调整
如果你像我一样从Delphi 8，Delphi 2005，Delphi 2006一路走来，那么你肯定会惊讶于CodeGear这一次在.NET平台上的新策略——No Windows Forms，No WPF，Only VCL for .NET。
本来VCL for .NET同WinForms就是重叠明显的两个框架。两个都存在的缘故之一就是VCL for .NET还不能完全代替WinForms——例如ECO当时不支持VCL for .NET。由于ECO 4正式加入了对VCL for .NET的支持，所以VCL for .NET终于可以全面代替WinForms了。Delphi for .NET也由此正式跳出了微软限定的.NET标准，建立了一个完全由CodeGear来主导的框架体系。一个很明显的好处就是CodeGear可以方便的加入新的API支持，例如VCL for .NET对于Vista新API的封装是十分完善的，远远超出了WinForms——后者只能利用一些蹩脚的方法直接呼叫Vista API来启用Vista特效。这样一来不论是VCL还是VCL for .NET现在都有了市场上对于Vista平台的最好支持——微软自己的Visual Studio反而是落后了许多。
另外，C#Builder也失去了和C++Builder、Delphi同等的地位，同VB.NET一样低人一等，只保留了代码编辑和简单调试的功能。我个人一直也认为CodeGear的R&D小组不应该同时支持那么多编程语言，现在看到这样的变化也在意料之中。
正是由于Delphi小组的精力完全放在了VCL和Delphi本身，可以想见这一次的VCL改进还有将来的Unicode VCL会给Delphi开发者带来怎样的变化。
当然，这也不意味着Delphi for .NET没有跟随.NET平台的进展。打开CodeGear Developer Network，你可以看到关于用Delphi for .NET进行WCF开发的文章，可以看到Delphi for .NET关于Generics的支持。虽然Delphi确实慢了一步，但是微软为.NET注入的各种所谓新特性也并不是说每一个都那么不可缺少——很多语法糖就很容易让初学者看得发晕，不是十分合适放在实际的项目中——除非真的是为了提升执行效率。
RAD Studio的未来
随着VCL地位的稳固已经Delphi小组重心的重新确立，我们可以期待在Win32和Win64平台上VCL和Delphi进一步提升的巨大空间。特别是Unicode VCL和RTL将在下一版本的Delphi中完成，可谓万众瞩目。毕竟微软的MFC实在是太不完美，ATL又始终不能完全取而代之，成熟可靠的VCL还是原生Windows平台开发中不可忽视的一股力量。
另一个值得期待的变化，将是Delphi语言对Generics的全面支持。下一版本的Delphi将会在Win32上面做出Generics来。这也似乎意味着Delphi也可以做出STL之类的容器。这也很可能会革命性的改变Delphi容器支持不是那么理想的问题。如果Delphi编译在这方面取得突破，Delphi和C++的相似性将得到进一步的提升，这也可能让Delphi进入之前无法触及的开发领域。
至于更远的未来，相信在Nick Hodges掌舵下Delphi小组会做出更多令人激动的创新，带领这一长寿的编程语言进入下一个开发的时代。
升级策略
首先，来介绍一下CodeGear的产品升级策略。之前的Borland模式大家相信也比较熟悉，简而言之就是Update有限。如果你需要修正更多bug的机会，请购买下一代的产品。当然，这也意味着Update不会带来新的特性。
虽然在Delphi 2005和Delphi 2006的时候这一策略有所松动，但是直到CodeGear成立，我们才有机会看到现在的新局面——Update也可以包含新的特性！当你将Delphi 2007和C++Builder 2007升级到Update 3，你的IDE立刻就开始支持AutoSave/AutoRecover了，而且又多出了BlackFish SQL这个小巧好用的数据库。这可都是RAD Studio 2007才加入的新东西呀！假如你还没有升级到Update 3，赶快行动吧！
Delphi for .NET的策略调整
如果你像我一样从Delphi 8，Delphi 2005，Delphi 2006一路走来，那么你肯定会惊讶于CodeGear这一次在.NET平台上的新策略——No Windows Forms，No WPF，Only VCL for .NET。
本来VCL for .NET同WinForms就是重叠明显的两个框架。两个都存在的缘故之一就是VCL for .NET还不能完全代替WinForms——例如ECO当时不支持VCL for .NET。由于ECO 4正式加入了对VCL for .NET的支持，所以VCL for .NET终于可以全面代替WinForms了。Delphi for .NET也由此正式跳出了微软限定的.NET标准，建立了一个完全由CodeGear来主导的框架体系。一个很明显的好处就是CodeGear可以方便的加入新的API支持，例如VCL for .NET对于Vista新API的封装是十分完善的，远远超出了WinForms——后者只能利用一些蹩脚的方法直接呼叫Vista API来启用Vista特效。这样一来不论是VCL还是VCL for .NET现在都有了市场上对于Vista平台的最好支持——微软自己的Visual Studio反而是落后了许多。
另外，C#Builder也失去了和C++Builder、Delphi同等的地位，同VB.NET一样低人一等，只保留了代码编辑和简单调试的功能。我个人一直也认为CodeGear的R&D小组不应该同时支持那么多编程语言，现在看到这样的变化也在意料之中。
正是由于Delphi小组的精力完全放在了VCL和Delphi本身，可以想见这一次的VCL改进还有将来的Unicode VCL会给Delphi开发者带来怎样的变化。
当然，这也不意味着Delphi for .NET没有跟随.NET平台的进展。打开CodeGear Developer Network，你可以看到关于用Delphi for .NET进行WCF开发的文章，可以看到Delphi for .NET关于Generics的支持。虽然Delphi确实慢了一步，但是微软为.NET注入的各种所谓新特性也并不是说每一个都那么不可缺少——很多语法糖就很容易让初学者看得发晕，不是十分合适放在实际的项目中——除非真的是为了提升执行效率。
RAD Studio的未来
随着VCL地位的稳固已经Delphi小组重心的重新确立，我们可以期待在Win32和Win64平台上VCL和Delphi进一步提升的巨大空间。特别是Unicode VCL和RTL将在下一版本的Delphi中完成，可谓万众瞩目。毕竟微软的MFC实在是太不完美，ATL又始终不能完全取而代之，成熟可靠的VCL还是原生Windows平台开发中不可忽视的一股力量。
另一个值得期待的变化，将是Delphi语言对Generics的全面支持。下一版本的Delphi将会在Win32上面做出Generics来。这也似乎意味着Delphi也可以做出STL之类的容器。这也很可能会革命性的改变Delphi容器支持不是那么理想的问题。如果Delphi编译在这方面取得突破，Delphi和C++的相似性将得到进一步的提升，这也可能让Delphi进入之前无法触及的开发领域。
至于更远的未来，相信在Nick Hodges掌舵下Delphi小组会做出更多令人激动的创新，带领这一长寿的编程语言进入下一个开发的时代。
扫一扫
849
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
