认识.NET Framework

2.1.3  Windows DNA存在的问题

Microsoft Windows DNA结构最初在1996年末、1997年初提出，当时Microsoft公司已经开始认识到Internet的巨大潜力。他们发行了Windows DNA，以帮助其他企业利用其战略(当然也向他们销售其平台)。

说明：

Windows DNA是一个编程模型或蓝图，利用它企业可以为Windows平台设计n层分布式基于组件的应用程序。而那时Microsoft就已经开始开发.NET了，不过那时候它的名称为COM+2.0。

Windows DNA应用程序无须使用Internet，但这却是大多数企业的首要考虑。这些年来，Windows DNA逐渐成熟，包含了可以在n层应用程序中使用的各种Microsoft产品和服务，以提供诸如消息收发和数据存储等功能。

Windows DNA的问题并不在于它的设计蓝图，其n层设计仍应用于.NET应用程序。Windows DNA的问题是由Microsoft公司或其他公司提供的工具组仍主要依靠90年代早期出现的COM以及使用专用语言和协议的Win32 API等老技术，这在今天肯定是一大缺陷。这初听起来会很令人惊讶，但想想开发人员在创建Web应用程序时所经历的痛苦，然后回答以下问题。Windows DNA平台便于使用吗？这个平台具有一致性吗？答案当然是“不”。

下面介绍Windows DNA的一些最为普遍的问题，之后简单介绍.NET是如何解决这些问题的。接着开始详细介绍.NET和CLR背后的推动技术。这些低层的技术推动和实现了像ASP.NET这样的高层技术的开发工作。

1. 停止全天候运行的应用程序

您是否尝试过替代Web服务器中的COM组件？或者替代开发用计算机上的COM组件？在.NET推出之前，必须先停止运行整个站点，再将文件复制进去，接着重新运行站点。更糟糕的是，有时必须重新启动计算机，因为COM和IIS产生了混淆，无法正确地发布文件。这在开发应用程序的过程中是非常痛苦的，对于必须一直运行的生产站点来说，这是无法接受的。造成这个问题的原因在于COM管理像DLL这样的文件的方式，即：一旦加载了像DLL这样的文件，除非在空闲的时间内进行卸载，否则根本无法改写它们，而在一台繁忙的网络服务器上是没有空闲时间的。

而.NET组件就不会这样。它们可以随时改写，这得益于Shadow Copy功能，它是CLR的一部分。我们编写的任何应用程序，以及像ASP.NET这样的Microsoft技术，都可以利用这项功能，它可以防止诸如DLL和EXE这样的PE(可移植的执行文件)文件被锁定。利用ASP.NET，对在bin目录中(这是应用程序使用的组件所在的目录)创建和放置的组件文件作出的任何修改都会自动检测。ASP.NET会自动加载被修改的组件，使用它们来处理当前未执行的所有新的Web请求，同时保留已加载的组件的老版本，直到先前的所有动态请求都已执行完毕。

2. 并排执行

Windows DNA的另一个问题是它不能很方便地在同一台计算机上或同一个处理过程中并排执行同一个应用程序的两个不同版本的组件。这个问题在windows xp中得到了改善，但在windows xp以前的版本中，仍然需要升级整个应用程序，才能使用最新的组件集，否则就会遇到很麻烦的情况。

.NET允许同一组件的不同版本同时存在，并且在同一台计算机上和同一个处理过程中并排执行。例如，一个ASP.NET Web页面使用某个组件的版本1，另一个ASP.NET Web页面使用该组件的版本2，虽然版本2和版本1不能相互兼容，但两者主要使用的类和方法的名称仍相同。由于使用该组件的Web页面(或另一个组件)有一定的依赖关系，因此可以识别并加载组件的正确版本，甚至在同一个处理过程中也是如此。这种同时运行相同代码的多个版本的功能称为并排执行。

说明：

利用并排执行功能，可以在同一台计算机上并排执行ASP.NET 1.0版、1.1版以及未来的所有版本，而不会发生任何冲突。这同样适用于.NET Framework。

3. 脚本限制

如果您是一个对编写组件不很熟悉(甚至根本不懂)的ASP开发人员，就可能发现无法在ASP页面中做任何事情。必须为页面编写、寻找或购买组件以实现需要的功能，例如注册表访问和安全，而这些功能都是Windows Platform的标准组成部分。

导致这个问题的原因在于ASP页面只能用脚本语言来编写，而脚本语言不能直接访问Win32 API，并且有许多和COM相关的限制。如果没有足够的资源或时间投入到组件开发上，这个问题就非常严重了。最好能够在ASP页面中完成所有的工作，仅在有时间并且能得到某种好处(如公共代码复用)时才使用组件。现在利用ASP.NET，就可以实现这些目标。

ASP.NET页面可以使用.NET Framework的所有功能。不必再为了处理脚本运行时间问题而编写组件(因为已经不再有什么脚本运行时间了)。可以决定在ASP.NET页面中使用什么代码，在组件中使用什么代码。在ASP.NET页面中代码已经不存在伸缩性问题了(但由于代码复用和维护的原因，创建组件仍然是个不错的选择)。

4. 版本化问题(DLL问题)

毫无疑问，Windows DNA的最大问题就是版本化。在创建应用程序时，通常包括许多复杂的相关组成部分，如标准DLL、ASP页面、以及COM DLL主控组件。ASP页面X若没有COM组件Y就无法运行，而COM组件Y需要DLL Z，DLL Z又依赖于更多的DLL，或像ADO 2.6这样的对象模型的特定版本。所有这些依赖关系都是隐式的(它们没有文档记录、不可见，或不能由操作系统实现)，但要使应用程序平稳运行，就必须满足这些依赖条件。

如果破坏了这些应用程序的依赖性，应用程序就无法正确地运行，更糟糕的是，应用程序可能在执行某个重要操作时停止。另外，许多组件还依赖多个应用程序共享的、系统通用的DLL和系统注册表中的值。要破坏应用程序是很容易的，只需安装另一个应用程序，或者使用诸如Regedit这样的工具来修改注册表。跟踪这些问题是一项非常困难的任务，尽管并非不可能。

为了解决版本化问题，.NET允许开发人员在不同软件组件之间指定版本和依赖性。这些依赖性和组件代码一起存储在一个程序集中(这里暂且可将程序集视为DLL或EXE文件)。.NET利用这些信息来确保应用程序的完整性，在无法加载组件、无法找到所需的依赖性或检测到文件已被篡改时报告错误。

为了进一步减少注册问题，.NET不再将注册表用于组件注册。有关类型(类、结构、枚举等)的信息都存储在代码中，在运行时直接从文件中检索该类型信息。当应用程序实例化一个像业务对象这样的新类型时，CLR会先扫描应用程序目录，接着扫描其他预定的位置，查找该组件。一旦找到了这个组件，该组件的信息就会高速缓存(由于性能的原因)，并在后续的请求中重复使用。这种分散注册的方式降低了应用程序之间由于错误而相互干扰的风险，组件也无需注册或注销。这样，部署应用程序就容易多了，只要将文件复制到某个目录中就可以了。

上一页  [1] [2] [3] 下一页