Commandlet vs Console App

Question

Я ищу руководство/документацию о том, когда создавать пользовательский PowerShell CMDLet и консольное приложение, и мне интересно, существуют ли определенные границы, где использование CMDLet плохое. Чтобы сделать этот вопрос более конкретным (и подотчетным), вот мой сценарий:

Я пытаюсь решить для импорта сценариев, импорт выполняется на платформе, которая предоставляет веб-сервисы, которые позволяют мне читать/писать данные.

У меня есть следующие требования (высокий уровень):

• вызова на веб-сервисы и получать данные для проверки, существует ли импортированные данные (и, возможно, требует обновления)
• Read (CSV) Импорт файлов макс размер 25MB
• Читайте комплексное отображение XML-файлов максимальный размер 2Мб
• должен быть скриптах (используется для автоматического развертывания, часть автоматизированного процесса сборки)

У меня теперь есть сомнения, что с CMDLet я могу делать все это, но мне интересно, является ли CMDLet правильным вариантом здесь. Я ищу ответ на свою конкретную ситуацию, но поскольку я только начинаю работу с CMDLets, я бы очень хотел получить дополнительную информацию о том, как сделать выбор здесь.

Answer 1

На мой взгляд, the're только два раза, когда это не нормально, чтобы построить CMDlet

1. Вы должны построить его быстро и просто нужно работать, (короткое время), или дон У вас много персонала, который знает, как использовать powershell.

2. Вам нужен импорт, чтобы поддерживающие сценариев быть кросс-платформенным с помощью Mono-проекта на Linux/Mac и т.д.

Кроме того, я думаю, что гибкость дает PowerShell не делает, строящим CMDlet ежу понятно.

Если вы создаете логику импорта в CMDLet в импортируемом модуле powershell, вы можете использовать всю инфраструктуру .net в сценарии powershell против вашего CMDlet.

В powershell вы получаете некоторые из своих требований прямо из ворот.

1. CSV-файлов, может PowerShell трубные CSV файлов без необходимости кодировать ничего там
2. файлов XML, можно также PowerShell трубы XML
3. Scriptable: Powershell является скриптовый движок.
4. Вызов WebService: Powershell can also call web services

Powershell был разработан, чтобы быть лучшей альтернативой для построения консольных приложений для командной строки. Так что, на мой взгляд, никогда не бывает плохой идеей использовать силу powershell.

На самом деле вы можете запустить всю инфраструктуру powershell в консольном приложении, превратив консольное приложение в командную строку powershell, и его довольно легко реализовать.

Writing a Powershell Host Application

Наш проект использует базы данных PowerShell на это логика импорта с помощью пользовательского модуля. Позволяя мне делать такие вещи, как,

1. перенесите-Сотрудники -source LegacyProd -destination Prod
2. Migrate-All -source LegacyProd -destination Prod
3. XYZDB-GetEmployee -EmployeeID 603
4. XYZDB-GetCustomer - CustomerID 000567
5. XYZDB-GetCustomer | Выберите CustomerID, Name, Address | Out-File c: \ customerDump.txt

И т.д., однако уведомление # 5 Это то, что делает powershell удивительным. В №5 я получаю дамп всех наших клиентов, которые выбирают только их идентификатор, имя и адрес и выгружают их в текстовый файл для ссылки. Мне не нужно было ничего кодировать, кроме GetCustomer CmdLet, остальное - все функции powershell.