Почему я должен выбрать Powershell над WMI для разработки интерфейсов управления?

Мы обсуждаем разработку усовершенствованной инфраструктуры управления для нашей распределенной системы. Мы используем COM, веб-службы и компоненты .NET. Поскольку мы основаны на Microsoft Windows Server XP/2003, я думаю, у нас в основном есть два варианта:

Командлеты Powershell
Классы WMI с использованием поставщиков System.Management и WMI для собственного кода (класс, экземпляр, метод, событие)

Почему мы выбираем Powershell над WMI?

Ответ 1

Я бы выбрал PowerShell поверх WMI по следующим причинам:

Написание командлета добавляет только класс .NET.
Сценарий PowerShell обеспечивает встроенный синтаксический анализ командной строки.
Написание вашего интерфейса управления в PowerShell позволяет администраторам интегрировать управление вашим приложением с другими приложениями и службами (например, Exchange, Active Directory или SQL Server).
Среда PowerShell делает конвейер доступным для администраторов, позволяя более эффективно выполнять задачи управления для вашего приложения.
Discoverability. PowerShell, через Get-Command, Get-Member и Get-Help, обеспечивает чрезвычайно открываемую среду для админов для работы, что приводит к более короткой кривой обучения для поддержки вашего приложения.

Даже если вы идете по маршруту WMI, у PowerShell есть поддержка для работы с WMI (хотя есть несколько сбоев).

Для меня PowerShell - это лучший способ для интерфейса ориентированного на задачи для приложения. Благодаря поддержке, которую Microsoft предоставляет PowerShell, она является и будет последовательным интерфейсом для управления приложениями и службами на предприятии.

Моя дневная работа - это как администратор, и я подталкиваю всех продавцов, с которыми я работаю, к разработке API управления PowerShell, поскольку это делает кривую обучения и переключение контекста для управления приложениями намного ниже. На стороне разработки я написал (и все еще работаю) серию командлетов PowerShell для одного продукта с открытым исходным кодом, с которым я работаю, и работаю над другим набором для отдельного приложения.

Ответ 2

Джеффри Сновер отвечает на вопрос "почему PowerShell" здесь. Сообщение находится в контексте SQL, но очень применимо здесь.

Ответ 3

Я не уверен, что смогу принять решение. Это не совсем так - или... вы можете сделать так.

WMI может потребляться множеством разных вещей, а не только PowerShell. Почему бы не написать свои инструменты управления в PowerShell, а затем обернуть этот WMI в некоторых командлетах, ориентированных на задачи, чтобы упростить работу с администраторами? Это то, что некоторые команды MS-продуктов предпочитают делать, особенно когда у них есть другие пользователи WMI, которые они хотят продолжать поддерживать.

Если у вас уже есть подходящий код .NET, включение этого в командлет может быть быстрее, чем превращение его в поставщика WMI. Если это случай, и скорость вызывает беспокойство, пойдите с тем, что проще. Но независимо от того, что вы делаете, вы всегда можете обернуть его в командлет PowerShell для администраторов, что, безусловно, является рекомендуемым.

Ответ 4

Не уверен, что на это можно ответить с информацией, которую вы предоставили до сих пор. Мое чувство кишки будет состоять в том, что вы должны использовать powershell, так как кажется, что у вас может быть какой-то код .Net. Но это действительно зависит только от того, что вы пытаетесь сделать.