【问题标题】:Applying powershell outside IT Management在 IT 管理之外应用 powershell
【发布时间】:2010-03-13 11:26:45
【问题描述】:

我们有一个灵活的过程控制系统,自动化工程师通过该系统配置包含数千个小逻辑单元的大型应用程序,这些逻辑单元经过参数化并集成到控制流中。

有许多在粒度级别上重复的任务,并且有许多专有的生产力工具可以满足这种需求。 我们有不同的业务部门,自动化工程师的技能和兴趣各不相同。花哨的 GUI 和可用性与灵活性是一个常见的讨论。

乍一看,Powershell 似乎是一个实施此类工具的明智平台,而且它也是管理整个系统设置和部署的 IT 方面的有利交叉技能。

这应该允许脚本精通他们想要的灵活性(他们已经是一个脚本人群)并且依赖于 GUI 的人仍然可以获得他们想要的由 powershell 支持的 GUI。

但我似乎找不到很多尝试广泛使用 powershell 的脚本化和对象传递来适应 IT 管理领域之外的异构用户社区的人/组。

有人有任何提示或警告吗? 关于为什么不应该这样做,我是否遗漏了一些明显的东西?

powershell 不应该接管世界吗? ;-)

【问题讨论】:

  • 我们使用了一些包含太多细节的工具。不同的业务部门具有不属于原始软件的利用率/工具支持。这种方法的另一个好处是从原始开发人员那里获得遵守正式模型的标准 cmdlet/提供者,而不是从旁观者那里获得。

标签: .net powershell system


【解决方案1】:

我完全同意你的观点,PowerShell 应该接管世界,而你的声明就是 PowerShell 的发展方向。

基于 PowerShell 的 GUI 非常有意义。我做了一个截屏视频How to Host PowerShell in a WPF Application

Microsoft Exchange 的 GUI 都在 PowerShell 之上。您可以在 GUI 中执行的操作可以在命令行中执行。 Exchange 甚至可以“记录”GUI 步骤并将它们呈现为 PowerShell 脚本。

走这条路会让你走上学习曲线。嵌入 PowerShell 引擎、运行空间、PSObject 集合、错误处理等。

目前还没有多少。

【讨论】:

    【解决方案2】:

    Powershell 显然能够胜任此类工作,而且随着时间的推移,它只会变得更加强大。它也是灵活和可扩展的,因此您可以在其中添加内容。显然,它的支持寿命将以几十年来衡量。明显的缺点是供应商锁定。

    【讨论】:

    • 我想我们很久以前就把我们的灵魂卖给了 MS。作为一名 .NET 开发人员,在这方面我感觉自己像个大天使 ;-) 但你的观点很好。
    猜你喜欢
    • 1970-01-01
    • 2018-08-17
    • 2021-12-31
    • 1970-01-01
    • 2011-01-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多