logo标签列表

为什么我会选择使用PowerShell开发管理界面而不是WMI呢？

powershellwmisystemmanagement
11

我们正在讨论为我们的分布式系统开发一个改进的管理基础架构。 我们使用COM、Web服务和.NET组件。由于我们基于Microsoft Windows Server XP/2003，我想我们基本上有两个选择：

  1. Powershell cmdlets
  2. 使用System.Management和WMI提供程序的WMI类来使用本地代码（类、实例、方法、事件）

为什么我们会选择Powershell而不是WMI？

4个回答
10
我会选择PowerShell而不是WMI，原因如下：
  1. 编写cmdlet只需添加.NET Class。
  2. PowerShell运行时内置命令行解析。
  3. 在PowerShell中编写管理界面使管理员能够将应用程序的管理与其他应用程序和服务（如Exchange、Active Directory或SQL Server）集成。
  4. PowerShell环境使得管理员可以使用管道更高效地完成应用程序的管理任务。
  5. 可发现性。通过Get-Command、Get-Member和Get-Help，PowerShell提供了一个极易被管理员发现的工作环境，从而缩短了学习曲线，便于维护您的应用程序。
即使您选择WMI路线，PowerShell也支持使用WMI（尽管有一些小故障）。
对我来说，PowerShell是向应用程序公开“以任务为导向”的接口的最佳方式。随着微软对PowerShell的支持，它已经成为并将继续成为企业管理应用程序和服务的一致接口。
我的日常工作是管理员，我正在推动我所使用的所有供应商开放PowerShell管理API，因为这会降低管理应用程序的学习曲线和上下文切换。在开发方面，我为一个开源产品编写了一系列PowerShell cmdlet，并正在为另一个应用程序编写另一组cmdlet。
4

Jeffrey Snover在这里回答了为什么要使用PowerShell。虽然文章是在SQL的背景下，但在这里也非常适用。

@halr9000，感谢您添加那个链接。我忘记了那篇文章。 - Steven Murawski
2

我不确定我会做出这个决定。这并不是非此即彼的选择... 你可以选择两者都做。

WMI可以被许多不同的东西所使用，不仅仅是PowerShell。为什么不在PowerShell中编写你的管理工具，并在一些面向任务的cmdlet中封装WMI，以便于管理员更容易地使用呢？这就是一些微软产品团队正在选择的方式，特别是当他们有其他的WMI消费者需要继续支持时。

如果你已经有了合适的.NET代码，将其转换为cmdlet可能比将其转换为WMI提供程序更快。如果是这种情况，并且速度是一个问题，那就选择更容易的方式。但无论你做什么，你总可以将它封装在一个PowerShell cmdlet中供管理员使用，这绝对是推荐的方法。

0

目前为止，根据您提供的信息，我不确定是否能够回答这个问题。我的直觉是，您应该使用PowerShell，因为它听起来您可能已经有一些 .Net 代码。但实际上，这取决于您要做什么。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接