数据仓库管理命令行应用程序 - PowerShell 或 C# 控制台应用程序
在回答这个问题时，我会说这是一家仅限微软的商店。
如果您要编写一个控制台应用程序来管理数据仓库，您会使用什么：
1) 为 PowerShell 编写自定义环境（最新版本的 Exchange / SQL Server）
2) 将其编写为 C# 控制台应用程序
如果 #2 是否有任何框架可以为您减轻编写“菜单系统”或任何其他任务的负担。
如果这个应用程序需要持续 6 到 8 年 - 您会使用 PowerShell 吗？ 目前团队中没有人有 PowerShell 经验，但我们学习速度很快。
I'll preface this question by saying this is for a Microsoft only shop.
If you were to write a console app to manage a data warehouse what would you use:
1) Writing a custom environment for PowerShell (ala the latest flavors of Exchange / SQL Server)
2) Write it as a C# Console App
If #2 are there any frameworks that offload writing a "menu system" or any other tasks for you.
If this app needed to last 6 to 8 years - would you use PowerShell?
No one on the team currently has PowerShell experience, but we are quick learners.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您将管理功能编写为 PowerShell cmdlet，那么您可以通过让人们直接运行 cmdlet 或将它们包装在 GUI 中来显示该功能。 使用 PowerShell 可能会给您带来最长期的灵活性，并且随着 MS 实现更多 PowerShell cmdlet，这意味着管理您的数据仓库可以在必要时与其他更大的业务流程合并。 我可能不会选择编写 C# 控制台应用程序 - 但我有一个明显更“管理员”的视角。 我们管理员厌倦了向我们扔来的自定义控制台应用程序 - PowerShell 的想法是以支持命令行和 GUI 管理的方式标准化一切。
If you write your management functionality as PowerShell cmdlets, then you can surface that functionality either by letting people run cmdlets directly, or by wrapping them in a GUI. Going with PowerShell probably gives you the most long-term flexibility, and as MS implements more PowerShell cmdlets, it means that managing your data warehouse could be incorporated with other, larger business processes if necessary. I would probably NOT choose to write a C# console app - but I have a distinctly more "administrator" perspective. We admins are tired of having custom console apps tossed at us - the idea of PowerShell is to standardize everything in a way that supports both command-line and GUI administration.
我认为你可以在两者上取得成功，并且应该能够在两者之间切换而没有太多麻烦。 如果您开始构建控制台应用程序但后来学习 PowerShell，则可以丢弃大量控制台应用程序特定的代码（例如命令行解析代码）并构建一些 PowerShell cmdlet 来包装现有的 API。 或者，如果您一开始构建了一堆 Cmdlet，但稍后需要切换到控制台应用程序，则您不会浪费太多时间来编写 Cmdlet。
所以，我确实没有任何强有力的建议。 我会说：嘿，去尝试一下 PowerShell。 如果你不喜欢它，切换起来也不是太困难。
I think you can be successful with both, and should be able to switch between the two without too much hassle. If you start out building a console app but learn PowerShell later, you can throw away a lot of the console app-specific code (command-line parsing code for example) and build a few PowerShell cmdlets to wrap your existing API. Or, if you build a bunch of Cmdlets out the gate, but need to switch to a console app later, you won't have wasted much time writing the Cmdlets.
So, I don't really have strong advice one way or another. I will say: hey, go try PowerShell. If you don't like it, it's not too difficult to switch.
我发现 PowerShell 对于较小的事情来说是一个更易于维护的解决方案。 当您依赖的库发生变化（在我的例子中是从 Visual Studio 2005 - Visual Studio 2008 的代码覆盖率和其他内容）以及脚本可能调用的可执行文件 vsinstr、mstest 等时，控制台应用程序需要重新链接到新库并重新编译和重新分发与 PowerShell 脚本一样，您可以轻松地针对您拥有的每个环境进行自定义，而不必为您选择的每个环境进行编译、链接、部署。 事实上，如果您从注册表获取路径信息，则相同的脚本可以在两种环境中运行。
你可以用任何一个来做你想做的事情，我只是更喜欢维护一个简单的文本文件，然后是一个控制台应用程序。 只是个人喜好。
I have found that PowerShell is a much more maintainable solution for smaller things. Console apps require relinking into new libraries and recompiling and redistributing out when the libraries you depend on change (in my case going from Visual Studio 2005 - Visual Studio 2008's codecoverage and other things) as well as executables your scripts may call vsinstr, mstest, etc. where as with PowerShell scripts you can easily customize for each environment you have and don't have to go through the compile, link, deploy stuff for every environment you choose. In fact if you get your path info from the registry the same script can run in both environments.
You can do everything you want with either, I just prefer having to maintain a single simple text file, then a console app. Just personal preference.
当您说管理数据仓库时，您在谈论什么类型的任务？
我将在 T-SQL 中进行大部分管理（清除、归档、转换）——其接口可能非常薄（甚至不存在）。
好的，根据您的评论，我将拥有使用 .NET 程序集（典型的 API 类库）在存储过程中完成所有工作的代码，尽可能多地在存储过程中，并使用在那里更容易完成的东西的程序集或者需要 COM 或其他什么。 然后，我要么将类库包装在 cmdlet 中，要么只从 PowerShell 调用 .NET 对象（请记住，PowerShell 可以实例化对象。）。
现在您有了一个 .NET 库，如果您需要的话，也可以从网页、GUI 应用程序等任何地方调用它，并且您有一个 cmdlet 和一个直接的 .NET 接口 - 加上从 SQL 调用它们的选项（如果它们是）完全在SQL层实现。
When you are saying manage a data warehouse, what kind of tasks are you talking about?
Much of the management I would do in T-SQL (purging, archiving, transforming) - the interface to that can be very thin (even non-existent).
OK, based on your comment I would have the code which does all the work in a stored procs with a .NET assembly (typical API class library), as much in stored procs as possible, with the assembly for stuff which is easier done there or which requires COM or whatever. I would then either wrap the class library in cmdlets or just call the .NET objects from PowerShell (remember that PowerShell can instantiate objects.).
Now you have a .NET library which can also be called from web pages, GUI apps, whatever, if you ever want it, and you have a cmdlet and a direct .NET interface - plus the option of calling them from SQL if they are fully implemented at the SQL layer.
实现 PowerShell 而不是控制台应用程序的优点在于，您不必编写所有参数解析或所有格式的代码。 PowerShell 会为您处理所有这些事情。 当然，如果需要，您可以覆盖默认值。 您可以免费获得通配符。 您还可以让 Cmdlet 从管道中获取值，这为自动化开辟了各种可能性和用途。 使用 PowerShell，最终用户和开发人员都将获得更好的体验。
The beauty of implementing PowerShell instead of a cosole app is that you don't have to code all the parameter parsing or all the formatting. PowerShell takes care of all of that for you. You can, of course, override defaults if you need to. You can get wildcards for free. You can also have your Cmdlet(s) take values from the pipeline which opens up all kinds of possibilities and uses for automation. With PowerShell, both the end user and the developer will have a much better experience.