br> 对于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 T代码编译
让我再重申一次:ASP.NET 代码现在被编译了.别紧张,这不是象你想的那样.你不需要创建文件,为了重新注册部件不得不stop 然后restart,现在不需要这样了,你只需照往常一样书写代码,仍然从早期捆绑中受益,系统会及时进行编译,
优化和缓冲存储. 这是怎样办到的呢?
根据脚本的首次请求, runtime将代码进行编译,并将编译结果进行高速缓冲存储复制(备份). 不论何时,只要脚本有请求,被存储的副本都可以调出使用. 此结果大大的增强了系统性能, 因为在首次请求之后,代码能更快的从编译版本中运行.
有人也许就会问了”它怎么知道我什么时候作了改动?” 微软已对此作出解答.Runtime通过文件系统来监视源文件. 当初始源文件发生改变时,它自动将编译版本从高速缓冲存储备份中拖出,因此当下一个要求来临时,它(编译文件)会被重新编译.这就意味着系统会自动编译代码, 程序员就再也用不着为人工编译而头疼了.
caching
对于多数的系统开发者而言,他们必须研制出一些“caching”来使系统速度加快。无论是ASP页面输出到HTML文件格式,网络联结速度都非常慢。或是从缓慢的internet链接引用,到recordset的 状态和漫游表单上的email表示符,甚至一个数据库动态驱动菜单,实际上不是完全的动态驱动,你不能为你每个客户请求而浪费大量时间。在创建网站时,一般来说,少量数据不会持续改变,但是正因为它们不是真正意义上的动态,不意味着使代码复杂化,那么它们在哪儿呢?所以,你得开发一些caching
基本的 caching 活动是首先甄选适当的数据进行存储。然后你需要将它们放置在程序中的application级变量中。然后,识别代码。然后,你就得决定得将数据存储多久,并写出程序,以便及时清空caching.但是,如果你清空了caching的话,那么所使用的程序得具有使数据重新恢复的功能。
在ASP.NET中建立了CACHING系统。使得使得整个系统比以前更为面向对象,使得 caching系统也可以存储 对象 。因此,无论何时caching,也可以随时调用。你可以根据需要设置数据存储的时间来决定创建各种类型的环境。 通过文件系统,你甚至可以在文件上链接一个详细的项目,这样当文件发生改变时,链接的项目就会同时被存储。
还不仅限于此,ASP.NET也存储输出数据。 为ASP。NET脚本结果做一个备份,因此当别人调用它时,他甚至不用运行,正确的输出结果就已在发送中。它主要基于查询字符串来工作,如果参数不能与存储中的参数相匹配,则记载参数的页面会回转到存储版本中
一些时候,依据站点来判断出什么需被存储是有一点技巧,但是至少现在不需要。
更快更简便的开发
任何开发平台都会向你提供一个固态的环境. 在ASP里,虽然这个环境的性能是优良的,但实际上它亳无用处.但是通过ASP.NET,在你书写你的第一行代码前,这个环境已为您做足了准备工作。以前程序员为了设计完善的程序,而不得不做的重复的烦人的工作,现在这个环境已为你做完了.
面向对象模型
当你的代码比以前任何时候都要运行得更快的时候,你已经得到一个真正的事件模型并可以对它进行控制。在过去,如果你希望某程序运行的早一些,你就不得不将程序放在页面的前面,相反,则放在页面的后部。这种方法往往不会起到很大的作用,所以你还得通过各种方法来构建你的代码以获得想要的效果. 这个“spaghett-code”问题能够通过使用大量的事件来修正,例如 page_load
每个页面级的对象都会有它们自己的事件模型,并且有能够激活设计好的Server事件。类似于 Button_Click 或 Listbox_Change 的例行程序,能够做出标准的表单处理,以及代你处理大量的相对简单的日常工作。读代码也成为可能,如此就意味着即使某段程序在六个月后出现了问题,也可以发现你以前的设定,并及时进行调试。