备案域名交易

如果我们想要使用ASP中的COM（可重复使用的编译代码），我们必须在服务器上注册组件。比如说，如果我们使用了Visual Basic开发了一种简单的数据访问组件，而且希望在ASP的应用程序中使用它，我们就必须在使用它之前显式的进行注册。组件的注册要么通过命令行工具regsvr32.exe，要么使用COM+Services（在start|programs|administrative tools|component services中可以找到）。在这两种情况下，都要在描述组件的windows记录中创建项，创建其线程模型，以及.dll文件的位置。然后我们就可以使用Server.CreateObject()方法写下ASP应用程序的代码。之后，我们将使用ProgID来找到记录中要求的组件的项。找到之后，就建立一个组件的示例。

很多开发人员把Application用作对于频繁使用的资源的高速缓存——例如读取一个给出了产品目录的XML文件，并把代表该XML文件的对象存储在Application内存中。但是，如果代表产品的XML文件发生改变的话，将会出现什么情况呢？在大多数情况下，使用Application来管理这种数据的开发人员只是使用Web应用程序重新启动，从而使Application得到刷新。 以前Cache的设计目标是让开发人员能够利用Application的各种优点，但同时它还提供了Application所不能提供的一些功能，比如说在文件发生变化的时候，从Cache中删除某项的内容——而要通过代码把该项内容重新添加到Cache中则是我们自己的事情了。 在Cache中基于依赖性的终止的功能非常强大，它可以使我们在Cache中的某项和某个文件、另一个Cache关键字或在时间中定义的点之间创建某种关系。比如说，如果我们在站点中使用了XML以及XSL转换来控制内容的某些方面，就可以把XML加载到类，并把值存储在Cache中。也可以使用Cache中基于文件的依赖性功能在高速缓存的XmlDocument和正在读取的文件。总之，用Cache来管理瞬间状态时离不开Application的使用，通过Application来读取XML文件中的数据。

Cache是一个在名称空间System.Web.Cache中的Cache类的实例。它除了和Application一样可作为简单的键或值对的Hashtable之外，它还支持其他的一些功能：1、基于依赖性的终止，依赖性可以是其他的Cache的关键字、文件或者时间戳记。如果其中一个依赖性发生改变或者中止（时间戳记），那么该项Cache内容就会无效并被从Cache中删除。2、锁定管理，和Application相似，并发的请求也可能会试图修改Cache。Application解决这个问题的办法是通过提供Lock()和UnLock()方法。不过，与Application不同的是，Cache类自己可以进行内部锁定管理。所以，尽管在更新Application时它需要我们明确地调用Lock()和UnLock()方法，但是对于Cache却不用这样做。请记住，和在Application中一样，在Cache中我们也需要对存储在其中的对象的并发进行管理。

暂时应用程序是由Cache（高速缓存）对象来控制的。Cache和Application的功能相似，因为它对于全部的web应用程序都是可访问的（共享的内存）。不过，Cache中增加了一些Application不具有的功能，包括相关、回调和超时。比如说，当启动ASP.NET应用程序的时候，我们必须从XML文件中生成一个由所有的ASP.NET页面使用的对象。我们可以把这个对象存储在Cache中，也可以为此在最初产生的数据的XML文件中创建一个相关性来保存它。如果XML文件发生了变化，ASP.NET将会发现文件的改变并且通知Cache使原来的条目无效。高速缓存是ASP.NET一个很强大的功能。但是我们使用时一定注意它和Application的区别。

与主要作为用户的专用存储器的Session不同，Application是共享的应用程序存储器。这种共享的存储器非常有用，在所有用户共享了某些资源（如某个站点的购物目录的XML表达式）的情况下尤其如此。与Session相似，Application状态只是一个存储关键字或值对组合的Hashtable。另外一方面，与Session不同的是，Application不支持独立于ASP.NET进程之外的数据存储。因为它是在ASP.NET进程中存储数据的。如果ASP.NET进程循环了，那么Application数据就会丢失。实际上，在进程中存储数据要比到其他检索数据块，而且到其他进程的过程中可能会出现跨网络的情况。

在ASP.NET页面中的所有移动控件放置在<mobile:form>表单中，每一个控件对应一个显示。目前显示的表单放置在页面的ActiveForm属性中，这样就可以编程方式改变显示——我们将经常在控件的事件处理程序中这样做。通过使用<mobile:form>表单生成的一个事件，可以得到一个简单的范例。它们创建两个事件，当激活或释放给定的表单时，就发生这些事件，并分别为OnActivate和OnDeactivate。可以在任何给定的表单上使用完全同名的属性向这些控件指派事件处理程序，并按照标准方式创建事件处理程序。因此，为了查看当前活动的表单的ID，可以使用代码（这些代码不是非常有用的，但是可以起到演示的目的）。

移动控件提供了低级移动应用程序设计的一种可行的替代方案。尽管对于传统的web设计员来说，它们有些难于使用，但是他们却具有强大的功能。然而，还有问题有待解决。首先，目前存在许多设备，它们配备多种浏览器，差别也很细微。即使是最好的开发小组也难于跟踪这种发展趋势。这意味着会不断地面临互用性问题。当考虑专用设备扩展时这个问题更为突出。为了最大化使用性，最可能做的就是扩展专用设备，这就导致即使在类似的设备之间也存在重大的代码区别。移动控件可以解决这个问题吗？从理论上来说可以。但是这要求开发人员做出极大的努力编写针对设备的代码。请注意，可扩展性架构已经到位，因此所有的工作都不会浪费！

计数器的创建和删除工作需要谨慎对待，因为它们实际上具有安装程序和卸载程序的特性。如果应用程序要求定制的计数器，则计数器应当在安装应用程序时创建，在卸载应用程序时删除。这种方法的一个问题是，如何使之与ASP.NET应用程序适合，在ASP.NET应用程序中使用全盘复制部署方法。解决这个问题的方法是：1、创建应用程序安装程序，这样就可以在正确的位置创建和删除计数器。2、创建单独的脚本或页面，以创建和删除计数器。3、检查在应用程序中是否存在计数器（也许是Application_OnStart事件），如果没有，则创建它们。如果卸载应用程序，这就留下了删除计数器的问题，以及性能问题，因为每次启动应用程序时都要检查它们。

重要的是将性能计数器值理解为值，而不是理解为条目——当将一个值写入性能计数器时，并不是在计数器中放置了永久的条目，如同将一个条目写入事件日志那样。性能计数器值是过渡性的，反映的是事件上的一点。当处理了引用特定系统计数器的最后一个PerformanceCounter组件时，计数器将自己重置为0。如果希望将值保留得比默认的计数器行为允许的更长一点的时间，则有几种方法可以管理性能计数器的生存期：1、可以在计数器驻留的服务器上运行Performance Monitor应用程序。只要Performance Monitor是打开的，就可以维护对计数器的引用，计数器值就可以继续累加。2、要确保总是有一个PerformanceCounter组件的实例连接到希望维护值的特定计数器上。3、可以编写保持对计数器引用的windows服务。

我们所认为的迁移就是通过最少量的代码变换，把应用程序的每一部分都移植到新的运行环境中。这是许多人所期待的目标，但要实现这一目标是要付出代价的。比如说，新的应用程序易于维护吗？是否想过添加代码使应用程序与ASP.NET保持一致，但结果却使代码甚至比以前更混乱？如果将来还需要更多工作的话，执行最少量工作的短期代价有可能更加昂贵。用户应该分析一下这种方法的代价，并将它与重写所需要的代价做一下比价，看看哪种方法才具有最好的长期效益。许多用户更倾向于选择重写。从零重新开始不仅有机会从新平台中得到最好的应用程序，还可以解决原来的应用程序中某些难以解决的问题。重写可以从.NET中获益最大，最后还有可能称为最廉价的解决方法。ASP.NET的程序员组之所以决定中断与ASP的兼容，有一个原因就是现在的用户使用网络越来越多，Microsoft希望新平台的支持时间能长一些。当然，重写方法有一个最大的问题，并不在于代码本身，而是对重写方法的学习。对于一种新的技术比如.NET，通常，培训和经验经常称为最大的障碍。