 .Net 新的可能性
如果你有 Visual Basic® 6.0 的背景，.NET Framework 就像沙漠中的一片绿洲。过去的挑战是把所有的核心功能需求都编到
某一个应用程序中。没有大量的时间和努力检测是不可能做好的。解决方案要么过于复杂（棘手的 C 动态链接库）要么太单纯（App.LogEvent）。很容易
引起让人难以接受的性能开销，它经常导致不完善的检测。
逆风者
具有讽刺意味的是如果不借助检测，你无法确切知道应用程序的局部运行得有多快。容量计划（预期负载分析与实际容量对比）是一个关键活动，当遇到基于 Web 的分布式
应用时，相对来说，这一点仍然是被忽视的。往往是体现在一个应用程序的表面，典型的实际客户如：Mercury Interactive的 LoadRunner 或微软的 ACT 工具。如果应用程序开始变慢了，
它慢在哪里？所有的环节都慢了么？那太不可能了，但你需要去证明之。好的检测可以回答这类问题并去掉许多猜测工作。
软件开发正经历着一场基本变化，开发者正试图尽力赶上这种变化。典型地基于 Web 的应用程序
的开发方法是将任务分割给单个开发者，构建新系统的某一个小部件并在单独的机器上测试。然后随同团队其余的工作一起将它部署到测试环境。从根本上说，这个过程是有缺陷的。基于
Web 的应用程序都是在单一的工作站上开发和测试，在那里它们运行良好。通常没有考虑一旦部署会有成千上万的用户点击，而不只是一个用户这一事实。通过早期的集成
来构建确认测试能大大有助于解决这样的问题。
综上所述，没有良好的检测，复杂的分布式应用程序是不可管理的。所以让我们看一下使用检测你可以完成什么。首先我将回顾一下传统的选项，然后考察在 .NET
Framework 中可利用的新可能性。
事件日志
事件日志（eventvwr.exe）一直是 Windows NT® 的一部分。它提供了集中记录日志信息的场所，其日志信息主要有三类：应用程序，系统和安全性。你可以向每个
分类中写信息，但通常关系最密切的是应用程序组。在 Visual Basic .NET 中执行下面的代码可以很容易实现： Imports System.Diagnostics
EventLog.WriteEntry("MyAppSource", "Details", System.Diagnostics.EventLogEntryType.Information)
有几件事情这里需要指出。如果你使用过 Visual Basic 6.0 的 App.Logevent，你会注意到你可以随意的定义自己的事件源（在事件查看器里面不再有 VBRuntime 长列表）。而且，过去创建事件描述实在是痛苦
，因为它们牵涉构建一个消息编译器资源文件并且要将它链接到应用程序 DLLs 中。现在由 .NET Framework 为你执行这些任务。在幕后，
该机制是一样的。查看注册表中下面的键值：
HKLM\System\CurrentControlSet\Services\EventLog\Application\MyAppSource
如果你把先前的代码片段放到一个 Windows 应用程序（Windows Application）项目里，就会有该键值。当事件描述被显示时它被 eventvr.exe（或任何其它的）读取
以定位你所引发的事件的描述。它指向一个通用的事件描述处理器，该处理器由.NET Framework 提供，位于：%WINDOWS%\Microsoft.NET\Framework\%version%\EventLogMessages.dll
这只是一个纯资源动态链接库，它必须带一个可替代参数 %l，它关联你在代码中指定给事件查看器的描述。当该语句被实际执行时，该注册表条目在运行时被添加，而不是在编译时。
虽然你可能很快会发现在注册表的 Application 键值下创建了一堆垃圾，那是因为每次你改变源文件参数时，你都会加入一个新的子键。这些子键将会永远的保存在注册表中除非你故意的
删除它们（这也是在开发初期要考虑检测的另一个原因）。
本文章更多内容：<<上一页 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 下一页>> | 
您的位置：逆风者
→ VC++
→ 正文
本文章所属分类：首页
→ VC++