Application de ligne de commande de Data Warehouse Management - Application pour console PowerShell ou C #

Question

Je vais commencer cette question en disant que ceci s’applique à un magasin Microsoft uniquement.

Si vous deviez écrire une application console pour gérer un entrepôt de données, qu'utiliseriez-vous:
1) Écriture d’un environnement personnalisé pour PowerShell (comme les dernières versions d’Exchange / SQL Server)
2) Ecrivez-le en tant qu'application console C #

Si # 2 existe-t-il des frameworks qui délèguent l'écriture d'un "système de menu" " ou toute autre tâche pour vous.

Si cette application devait durer 6 à 8 ans, utiliseriez-vous PowerShell? Aucun membre de l'équipe n'a actuellement l'expérience de PowerShell, mais nous apprenons vite.

Answer 1

Si vous écrivez votre fonctionnalité de gestion en tant qu'applets de commande PowerShell, vous pouvez afficher cette fonctionnalité en laissant les utilisateurs les exécuter directement, ou en les enveloppant dans une interface graphique. Utiliser PowerShell vous offre probablement la plus grande flexibilité à long terme. Si MS implémente davantage d'applets de commande PowerShell, cela signifie que la gestion de votre entrepôt de données peut être intégrée à d'autres processus plus importants, si nécessaire. Je ne choisirais probablement PAS d’écrire une application pour console C #, mais j’ai un nombre nettement plus important d’administrateurs et administrateur; la perspective. Nous, les administrateurs, en avons assez des applications de console personnalisées. L’idée de PowerShell est de tout normaliser de manière à prendre en charge l’administration en ligne de commande et l’interface utilisateur graphique.

Answer 2

Je pense que vous pouvez réussir avec les deux et que vous devriez pouvoir basculer entre les deux sans trop de tracas. Si vous commencez à créer une application console mais apprenez PowerShell plus tard, vous pouvez jeter une grande partie du code spécifique à cette application (code d'analyse de ligne de commande, par exemple) et créer quelques applets de commande PowerShell pour envelopper votre API existante. Ou, si vous créez un ensemble d’applets de commande par la porte, mais que vous devez basculer ultérieurement vers une application console, vous n’aurez pas perdu beaucoup de temps à les écrire.

Donc, je n'ai pas vraiment de bons conseils d'une manière ou d'une autre. Je vais dire: hé, allez essayer PowerShell. Si vous ne l'aimez pas, il n'est pas trop difficile de changer.

Answer 3

J'ai constaté que PowerShell est une solution beaucoup plus facile à gérer pour les petites choses. Les applications de console nécessitent de se relier à de nouvelles bibliothèques et de recompiler et redistribuer lorsque les bibliothèques sur lesquelles vous comptez changer (dans mon cas, passant de Visual Studio 2005 à Codecoverage de Visual Studio 2008 et autres), ainsi que les exécutables que vos scripts peuvent appeler vsinstr, mstest, etc. Où, comme avec les scripts PowerShell, vous pouvez facilement personnaliser chaque environnement que vous avez et ne pas avoir à passer par les tâches de compilation, de liaison et de déploiement pour chaque environnement de votre choix. En fait, si vous obtenez vos informations de chemin du registre, le même script peut être exécuté dans les deux environnements.

Vous pouvez faire tout ce que vous voulez, je préfère simplement conserver un seul fichier texte, puis une application console. Juste préférence personnelle.

Answer 4

Lorsque vous parlez de gérer un entrepôt de données, de quel type de tâches parlez-vous?

Une grande partie de la gestion que je ferais dans T-SQL (purger, archiver, transformer) - l'interface avec celle-ci peut être très mince (voire inexistante).

OK, sur la base de votre commentaire, j'aurais le code qui effectue tout le travail dans un processus stocké avec un assemblage .NET (bibliothèque de classes d'API typique), autant que possible dans les processus stockés, avec l'assembly for stuff, qui est plus facile à faire ou qui nécessite COM ou autre chose. Je voudrais ensuite envelopper la bibliothèque de classes dans des applets de commande ou simplement appeler les objets .NET à partir de PowerShell (rappelez-vous que PowerShell peut instancier des objets.).

Vous disposez maintenant d'une bibliothèque .NET qui peut également être appelée à partir de pages Web, d'applications GUI ou de tout autre logiciel, si vous le souhaitez, ainsi que d'une applet de commande et d'une interface .NET directe, sans oublier de les appeler à partir de SQL. si elles sont entièrement implémentées au niveau de la couche SQL.

Answer 5

L'intérêt d'implémenter PowerShell au lieu d'une application cosole est qu'il n'est pas nécessaire de coder tout l'analyse des paramètres ou toute la mise en forme. PowerShell s'occupe de tout cela pour vous. Vous pouvez bien sûr remplacer les valeurs par défaut si vous en avez besoin. Vous pouvez obtenir des jokers gratuitement. Vous pouvez également demander à votre applet de commande de prendre des valeurs du pipeline, ce qui ouvre toutes sortes de possibilités et d'utilisations pour l'automatisation. Avec PowerShell, l’utilisateur final et le développeur bénéficieront d’une bien meilleure expérience.