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

Question

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

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

Почему мы выбрали Powershell вместо WMI?

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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