Powershell模块/脚本应该接受对象作为输入吗？

Question

我的团队最近有一场辩论。我们需要创建一个Powershell模块，定义几个将在各种脚本中重用的函数。

一些团队成员认为，模块中公开的函数应该以对象作为参数，而不是2或3个原始类型参数。其他人认为，如果查看Powershell的基本命令，尽管它们可能返回对象，但它们从不将对象作为参数。

考虑到多么乏味，与“真正的面向对象”语言相比，用Powershell操纵对象，您认为它值得额外的成本吗？关于将对象作为输入，有什么公认的最佳实践吗？

一般来说，是在完全传统的面向对象思想的基础上设计的，或者它的命令行特性必然会破坏我们如何编写和使用Powershell代码?。

Answer 1

其他人认为，如果查看Powershell的基本命令，尽管它们可能返回对象，但它们从不将对象作为参数。

那是垃圾。那Stop-Process呢，我头上的第一个例子呢？您可以传递给它一个整数数组(进程id)、一个字符串数组(进程名)或一个Process对象数组：

语法 停止进程-Id -PassThru -WhatIf停止进程-Name -PassThru -WhatIf停止进程-InputObject -PassThru -WhatIf

也可能是Remove-Item，它接受-Path或-LiteralPath参数，但同样会接受任何具有Path或LiteralPath属性的对象。而且，与许多其他cmdlet一样，它有一个-Credential参数，它是一个pscredential对象，可以在命令行上指定，也可以在管道对象上指定属性。

遵循这些标准的cmdlet作为您的模型:cmdlet的主要参数通常是某个原语的数组，但也可以是管道中适当对象的属性或对象数组。如果有适当的对象，则接受它为参数集之一，但尝试拥有允许命令自行运行的其他参数集。

其他参数(-Credential是最明显的例子)与对象一样做得很好。

Answer 2

我会使用原语类型作为论据(接吻)。在内部，Powershell将把一切都转化为PSObjects。不管你给它苹果还是橘子，都是水果沙拉。

除此之外，随着云计算变得更加流行，远程管理成为常态，您使用的任何东西最终都很可能被序列化并发送到网络上。基本类型通常比dotnet对象更高效、更可预测地序列化，并产生更小的有效负载。

国际水文学