Aplicación de línea de comandos de Data Warehouse Management: aplicación de consola PowerShell o C #

Question

Prefacio a esta pregunta diciendo que esto es para una tienda exclusiva de Microsoft.

Si tuviera que escribir una aplicación de consola para administrar un almacén de datos, ¿qué usaría:
1) Escribir un entorno personalizado para PowerShell (los últimos sabores de Exchange / SQL Server)
2) Escríbelo como una aplicación de consola C #

Si # 2 hay marcos que descarguen la escritura de un " sistema de menú " o cualquier otra tarea para usted.

Si esta aplicación tuviera que durar de 6 a 8 años, ¿usaría PowerShell? Actualmente, nadie en el equipo tiene experiencia en PowerShell, pero aprendemos rápidamente.

Answer 1

Si escribe su funcionalidad de administración como cmdlets de PowerShell, puede mostrar esa funcionalidad permitiendo que las personas ejecuten cmdlets directamente o envolviéndolas en una GUI. Optar por PowerShell probablemente le brinde la mayor flexibilidad a largo plazo, y a medida que MS implemente más cmdlets de PowerShell, significa que la administración de su almacén de datos podría incorporarse a otros procesos comerciales más grandes si fuera necesario. Probablemente NO elegiría escribir una aplicación de consola de C #, pero tengo un 'administrador' claramente más perspectiva. Los administradores estamos cansados ??de que nos arrojen aplicaciones de consola personalizadas: la idea de PowerShell es estandarizar todo de una manera que admita la administración de la línea de comandos y la GUI.

Answer 2

Creo que puede tener éxito con ambos, y debería poder cambiar entre los dos sin demasiados problemas. Si comienza a construir una aplicación de consola pero luego aprende PowerShell, puede desechar gran parte del código específico de la aplicación de la consola (código de análisis de línea de comandos, por ejemplo) y construir algunos cmdlets de PowerShell para ajustar su API existente. O bien, si crea un conjunto de Cmdlets por la puerta, pero necesita cambiar a una aplicación de consola más tarde, no habrá perdido mucho tiempo escribiendo los Cmdlets.

Entonces, realmente no tengo un buen consejo de una forma u otra. Diré: hey, ve a probar PowerShell. Si no te gusta, no es muy difícil cambiarlo.

Answer 3

He descubierto que PowerShell es una solución mucho más fácil de mantener para cosas más pequeñas. Las aplicaciones de consola requieren volver a vincular a nuevas bibliotecas y volver a compilar y redistribuir cuando las bibliotecas de las que depende cambien (en mi caso, desde Visual Studio 2005, la cobertura de código de Visual Studio 2008 y otras cosas), así como ejecutables que sus scripts pueden llamar vsinstr, mstest, etc. donde, al igual que con los scripts de PowerShell, puede personalizar fácilmente para cada entorno que tenga y no tiene que pasar por la compilación, el enlace y la implementación de elementos para cada entorno que elija. De hecho, si obtiene su información de ruta del registro, el mismo script puede ejecutarse en ambos entornos.

Puedes hacer todo lo que quieras con cualquiera, solo prefiero tener que mantener un solo archivo de texto simple, luego una aplicación de consola. Solo preferencia personal.

Answer 4

Cuando dice administrar un almacén de datos, ¿de qué tipo de tareas está hablando?

Gran parte de la gestión que haría en T-SQL (depuración, archivo, transformación): la interfaz puede ser muy delgada (incluso inexistente).

OK, según su comentario, tendría el código que hace todo el trabajo en un proceso almacenado con un ensamblado .NET (biblioteca de clases de API típica), tanto como sea posible en los procesos almacenados, con el ensamblaje para cosas que son más fácil de hacer allí o que requiere COM o lo que sea. Luego, envolvería la biblioteca de clases en cmdlets o simplemente llamaría a los objetos .NET desde PowerShell (recuerde que PowerShell puede crear instancias de objetos).

Ahora tiene una biblioteca .NET que también se puede llamar desde páginas web, aplicaciones GUI, lo que sea, si alguna vez lo desea, y tiene un cmdlet y una interfaz .NET directa, más la opción de llamarlos desde SQL si están completamente implementados en la capa SQL.

Answer 5

La belleza de implementar PowerShell en lugar de una aplicación cosole es que no tiene que codificar todo el análisis de parámetros o todo el formato. PowerShell se encarga de todo eso por usted. Por supuesto, puede anular los valores predeterminados si es necesario. Puedes obtener comodines gratis. También puede hacer que sus Cmdlet (s) tomen valores de la tubería que abre todo tipo de posibilidades y usos para la automatización. Con PowerShell, tanto el usuario final como el desarrollador tendrán una experiencia mucho mejor.