对于COM对象不再需要再在服务器上注册的这个功能我们是非常喜爱的。但是通过这种过程简化，我们也能也许会在不经意间将一罐蠕虫病毒打开。这些恶梦躲藏在DLL背后的一个原因（就象我们愤恨的那样）即是它加强了版本的保密性。你再也不能够在你的服务器上运行 另外一个DLL版本，并且代码相当保密，这意味着，如果没有正确的开发工具和源代码，很难改变代码。
这个安全的机制，现在已经删掉了。你可以在你的服务器上运行任何你想运行的DLL版本，这些DLL可能会导致各种令人头痛的问题和安全方面的噩梦。
许多开发者喜欢COM对象的另一个很大便利之处是，你可以将你的商业逻辑打包，除了开发者之外，没人能看到它----对象是被编译过的，因此你的客户是看不到的。在新的框架里，你必须得用应用程序来分散源文件，因为NGWS一定会追踪源文件的轨迹。最终用户能够按他们的意愿浏览或者修改代码。当然，你也可以将 对象 编译，或者不给出源文件，但是随之而来的是，你会失去NGWS所提供的一些便利功能，这是得不偿失的。
你也要密切留意那些进入你文件的人可能使用的一些源控制之外的东西（例如：Visual Source Safe）。那么任一用户都会相当容易的进入或者修改你的 objects，那么去想想那些黑客们吧。
对于XML来说，这些问题同样适用。任何人都能轻而易举的黑了你。
适应性
肯定的是，通常任何一个全新的技术，在市场渗透都会花费一些时间。微软正在开始让ASP和IIS平台通过行业验证，以便让其作为其它网络服务器之外可以供选择的平台
对于在其基本构架上的如此巨大的改变，是很难说服客户或者开发人员丢弃他们以前所使用的方法而来改用现有的方法。当然，随着时间的流逝，问题总是会被慢慢的解决，但事实上，ASP+要被市场接受，所面临的是一道障碍；即使慢慢的被采纳，寻找高品质解决方案和技术支持方面的问题也会接踵而来。事实上，ASP.net仍然是个alpha 技术，但在寻求支持方面，它又是如此幸运。
现存代码
当然，在将系统转换成 ASP.net之前，你得将你所有现存的代码重写一遍。你的那些旧的代码仍旧会在IIS内运作，但你仍然将使用传统的ASP框架（这不是件坏事）。当然，将一个庞大的web 应用程序移植到ASP.net中是一件非常痛苦的过程，特别是你已经有大量的解决方案或者说是COM对象。
ASP.NET代码编译
让我再重申一次:ASP.NET 代码现在被编译了.别紧张,这不是象你想的那样.你不需要创建文件,为了重新注册部件不得不stop 然后restart，现在不需要这样了，你只需照往常一样书写代码,仍然从早期捆绑中受益，系统会及时进行编译。
优化和缓冲存储. 这是怎样办到的呢?
根据脚本的首次请求, runtime将代码进行编译,并将编译结果进行高速缓冲存储复制(备份). 不论何时,只要脚本有请求,被存储的副本都可以调出使用. 此结果大大的增强了系统性能, 因为在首次请求之后,代码能更快的从编译版本中运行.
有人也许就会问了”它怎么知道我什么时候作了改动?” 微软已对此作出解答.Runtime通过文件系统来监视源文件. 当初始源文件发生改变时,它自动将编译版本从高速缓冲存储备份中拖出,因此当下一个要求来临时,它(编译文件)会被重新编译.这就意味着系统会自动编译代码, 程序员就再也用不着为人工编译而头疼了.
caching
对于多数的系统开发者而言，他们必须研制出一些“caching”来
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
