为什么我会选择 Powershell 而不是 WMI 来开发管理界面？
我们正在讨论为我们的分布式系统开发改进的管理基础设施。 我们使用 COM、Web 服务和 .NET 组件。 由于我们基于 Microsoft Windows Server XP/2003，我想我们基本上有两个选择：
- Powershell cmdlet
- 使用 System.Management 的 WMI 类和本机代码的 WMI 提供程序（类、实例、方法、事件）
为什么我们选择 Powershell 而不是 WMI？
We are discussing development of an improved management infrastructure for our distributed system.
We use COM, web services and .NET components. Since we're based on Microsoft Windows Server XP/2003, I guess, we basically have two options:
- Powershell cmdlets
- WMI classes using System.Management and WMI providers for native code (class, instance, method, event)
Why would we choose Powershell over WMI?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我会选择 PowerShell 而不是 WMI，原因如下：
即使您采用 WMI 路线，PowerShell 也确实支持使用 WMI（尽管存在一些故障）。
对我来说，PowerShell 是向应用程序提供面向任务界面的最佳方式。 凭借 Microsoft 一直提供的 PowerShell 支持，它现在和将来都是管理整个企业应用程序和服务的一致界面。
我的日常工作是管理员，我正在推动所有与我合作的供应商提供 PowerShell 管理 API，因为这使得管理应用程序的学习曲线和上下文切换要低得多。 在开发方面，我已经为我使用的一个开源产品编写了（并且仍在研究）一系列 PowerShell cmdlet，并且正在为单独的应用程序编写另一组 cmdlet。
I would choose PowerShell over WMI for the following reasons:
Even if you go the WMI route, PowerShell does have support for working with WMI (though there are a few glitches).
To me, PowerShell is the best way to surface a task oriented interface to an application. With the support Microsoft has been providing PowerShell, it is and will be a consistent interface to managing applications and services throughout the enterprise.
My day job is as an admin and I'm pushing all the vendors I work with towards surfacing a PowerShell management API, as this makes the learning curve and context switching for managing applications much lower. On the development side, I have written (and am still working on) a series of PowerShell cmdlets for one open source product I work with and am working on another set for a separate application.
Jeffrey Snover 回答了“为什么使用 PowerShell”此处。 这篇文章是在 SQL 的背景下进行的，但在这里非常适用。
Jeffrey Snover answers the "why PowerShell" here. The post is in the context of SQL, but very much applicable here.
我不确定我是否会做出决定。 这并不完全是非此即彼……你可以选择两者都做。
WMI 可以被许多不同的东西使用，而不仅仅是 PowerShell。 为什么不在 PowerShell 中编写管理工具，然后将该 WMI 包装在一些面向任务的 cmdlet 中，以使管理员的工作变得更轻松？ 这就是一些 MS 产品团队选择做的事情，特别是当他们有其他 WMI 消费者想要继续支持时。
如果您已经有了合适的 .NET 代码，将其转换为 cmdlet 可能比将其转换为 WMI 提供程序更快。 如果是这种情况，并且速度是一个问题，那就选择更容易的方法。 但无论您做什么，您始终可以将其包装在管理员的 PowerShell cmdlet 中，这绝对是推荐的方法。
I'm not sure I'd make the decision. It's not exactly either-or... you can choose to do both.
WMI can be consumed by a number of different things, not just PowerShell. Why not write your management instrumentation in PowerShell, and then wrap that WMI in some task-oriented cmdlets to make things easier on administrators? That's what some MS product teams are choosing to do, especially when they have other consumers of WMI they want to continue supporting.
If you've already got suitable .NET code, turning that into a cmdlet may be faster than turning it into a WMI provider. If that's the case, and speed is a concern, go with what's easier. But no matter what you do, you can always wrap it in a PowerShell cmdlet for admins, which is definitely the recommended approach.
不确定您目前提供的信息是否可以回答这个问题。 我的直觉是你应该使用 powershell，因为听起来你可能已经有了一些 .Net 代码。 但这确实取决于您想要做什么。
Not sure that this can be answered with the information that you have provided so far. My gut feeling would be that you should use powershell since it sounds like you may already have some .Net code. But it really does just depend on exactly what you are trying to do.