更好的是下面的代码,它比刚才所示的更有效。<System.ComponentModel.RunInstaller(True)>_
Public Class MyEvent _
Inherits BaseEvent
''Event "property"
Public EventProp as String
End Class
你可以很容易引发事件,Dim objEvent as MyEvent
objEvent = new MyEvent
objEvent.EventProp = "Hello world!"
Instrumentation.Fire(objEvent)
该代码段给 WMI 发布了一个事件,它支持松耦合发布/订阅模型。WMI 让你引发事件,该事件将被传递到它们的订阅者,如果还没有订阅者运行,则在以后一旦有订阅者时
,该事件便能被拾起。这意味着即使你知道没有监听,也不会产生实际发布事件时的开销。 逆风者
写自己的监听器的一个好理由就是可以很好的利用公司已经有的日志工具,比如现
有的向中央数据库写日志的 COM 组件,这个被系统使用的数据库也支持个人编写所有应用程序。
WMI 是基于标准的;它是 Distributed Management Task Force (DMTF)、WBEM 发起者、和 DMTF
Common Information Model(CIM)的实现。更多细节请访问
http://www.dmtf.org。
只要钻研一下你就会找到这些缩写词。WMI 能够同 SNMP程序进行互操作,使得真正想要实现集中化监视的企业成为可能。在异类的 Web 服务世界里,
异类的检测能力是不可缺少的。
为了开始使用这些事件,使用合适的 WMI 范围和查询创建System.Management.ManagementEventWatcher,并为 EventArrived 事件注册
一个事件处理器。Figure 3 代码示范了一个简单的事件处理器代码。
你甚至可以使用 WMI 服务器资源管理器扩展使其变得更简单(参见微软下载中心的 “Managed WMI Extensions for Visual
Studio .NET 2003 Server Explorer”)。你可以仅建立一个事件的查询(用 WQL,SQL 的子集),并将它们拖拽到窗体上。我所展示的代码都是当时产生的。
好的,坏的和糟糕的
现在让我们看一下通过考察各个选项的优缺点,从而确定何时应该使用或不应该使用每个选项。
事件日志有很多好处。它容易使用,持久耐用,还可以从远程机器上查看或者将事件日志记录到远程机器。你甚至可以定期的存储日志为以后的研究和报表使用。不幸的是在大部分现实情况下其缺点掩盖了其优点。事件日志是有
局限的。在创建事件日志时你可以设定其大小,然后其大小就是固定的了。从这点来看,要么日志尝试抛出异常,要么是用配置对日志进行包装,首先改写早期编写的条目。由于这个限制,事件日志
只是在记录少量信息时很有用,比如像程序启动和停止消息或者更高级别的通知消息等关键事件。另外,只有 Windows NT 上才有这个工具,如果你
仍然面向 Windows 98 和 Windows Me,这两个操作系统是不提供该工具的。
性能计数器非常有用。它们提供了对程序健康状况
极好的综合统计。对于研究与负载有关的问题,已连接客户端数,数据库连接数,平均换页次数都是理想的度量。同样,由于有了事件日志机制,性能计数器并不适合
大量专门细节信息。性能计数器使用平均运行值或绝对值工作。计数器之所以有用是因为 Perfmon 提供了远程机器访问和文件日志。它甚至提供了报警机制,举个例子,运行一个程序发送一个电子邮件或者短信息(SMS),
是否平均响应时间超过了某个 SLA 。
跟踪是 CLR 领域的真正福音。内建支持提供的功能不用做任何修改便能使用(out-of-the-box),并且 .NET Framework 允许你使用它提供的跟踪处理器
,或者也可以实现自己的处理器。 本文章更多内容:<<上一页 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 下一页>> |