Приложение командной строки для управления хранилищем данных - консольное приложение PowerShell или C #

Question

Я предрежу этот вопрос, сказав, что это только для магазина Microsoft.

Если бы вы написали консольное приложение для управления хранилищем данных, что бы вы использовали:
1) Написание пользовательской среды для PowerShell (все последние версии Exchange / SQL Server)
2) Напишите это как консольное приложение C #

Если # 2, существуют ли какие-либо фреймворки, которые разгрузят написание «системы меню» или любые другие задачи для вас.

Если бы это приложение длилось от 6 до 8 лет - вы бы использовали PowerShell? В настоящее время никто из команды не имеет опыта работы с PowerShell, но мы быстро учимся.

Answer 1

Если вы пишете свои функции управления в виде командлетов PowerShell, то вы можете использовать эти функции, либо позволяя людям запускать командлеты напрямую, либо помещая их в графический интерфейс. Использование PowerShell, вероятно, обеспечивает максимальную гибкость в долгосрочной перспективе, а поскольку MS внедряет больше командлетов PowerShell, это означает, что управление хранилищем данных может быть включено в другие, более крупные бизнес-процессы, если это необходимо. Я бы, вероятно, НЕ решил написать консольное приложение на C #, но у меня явно более "администраторская" точка зрения. Мы, администраторы, устали от того, что нам бросают пользовательские консольные приложения. Идея PowerShell - стандартизировать все таким образом, который поддерживает администрирование как из командной строки, так и из GUI.

Answer 2

Я обнаружил, что PowerShell - это гораздо более удобное решение для небольших задач. Консольные приложения требуют повторного подключения к новым библиотекам, перекомпиляции и перераспределения, когда библиотеки, от которых вы зависите, меняются (в моем случае это переход от Visual Studio 2005 - кодовое покрытие Visual Studio 2008 и другие вещи), а также исполняемые файлы, которые ваши скрипты могут вызывать vsinstr, mstest и т. Д. где, как и в случае сценариев PowerShell, вы можете легко настраивать их для каждой имеющейся среды, и вам не нужно проходить компиляцию, компоновку, развертывание для каждой выбранной вами среды. Фактически, если вы получаете информацию о пути из реестра, один и тот же сценарий может выполняться в обеих средах.

Вы можете делать все что угодно, я просто предпочитаю поддерживать один простой текстовый файл, а затем консольное приложение. Просто личные предпочтения.

Answer 3

Я думаю, что вы можете добиться успеха с обоими, и должны иметь возможность переключаться между ними без особых хлопот. Если вы начинаете создавать консольное приложение, но изучаете PowerShell позже, вы можете выбросить много кода, специфичного для консольного приложения (например, код синтаксического анализа командной строки), и создать несколько командлетов PowerShell для переноса существующего API. Или, если вы создаете кучу командлетов из шлюза, но позже вам нужно переключиться на консольное приложение, вам не придется тратить много времени на написание командлетов.

Итак, у меня нет сильных советов, так или иначе. Я скажу: эй, иди попробуй PowerShell. Если вам это не нравится, переключаться не сложно.

Answer 4

Прелесть внедрения PowerShell вместо приложения cosole заключается в том, что вам не нужно кодировать весь анализ параметров или все форматирование. PowerShell позаботится обо всем этом для вас. Вы можете, конечно, переопределить значения по умолчанию, если вам нужно. Вы можете получить групповые символы бесплатно. Вы также можете сделать так, чтобы ваш командлет (ы) брал значения из конвейера, который открывает все виды возможностей и использует их для автоматизации. С PowerShell и конечный пользователь, и разработчик получат гораздо лучший опыт.

Answer 5

Когда вы говорите об управлении хранилищем данных, о каких задачах вы говорите?

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

ОК, основываясь на вашем комментарии, у меня был бы код, который выполняет всю работу в хранимых процессах со сборкой .NET (типичная библиотека классов API), насколько это возможно в хранимых процессах, со сборкой для материала, который там легче сделать или что требует COM или что-то еще. Затем я бы либо обернул библиотеку классов в командлеты, либо просто вызвал объекты .NET из PowerShell (помните, что PowerShell может создавать объекты).

Теперь у вас есть библиотека .NET, которую также можно вызывать из веб-страниц, приложений с графическим интерфейсом, чего угодно, если вы когда-либо захотите, и у вас есть командлет и прямой интерфейс .NET - плюс возможность вызывать их из SQL если они полностью реализованы на уровне SQL.