Manage Learn to apply best practices and optimize your operations.

A task-based approach to PowerShell cmdlet design

Unlike developers, many admins prefer the "more cmdlets, the better" approach when performing tasks in Windows PowerShell.

Several years ago I had a discussion with a colleague about how Windows PowerShell functions/cmdlets should be...

designed. As a developer by trade, he liked the idea of having a small number of cmdlets that output objects through several methods. I can definitely see the benefit of this approach -- for a developer.

But for IT admins, this really turns us off. Calling methods on the output of a command is completely foreign to administrators; we are used to running a command and getting back the data we want. I love the idea of having task-based cmdlets that perform a single action and provide feedback related to that task. Using this approach is more conducive to the command line and makes the pipeline a very powerful tool.

Therefore, I want to make a case for using task-based cmdlets instead of methods when designing PowerShell commands. While several vendors have done a good job of producing cmdlets for PowerShell (Citrix and IBM, to name a couple), I feel the VMware team in particular has excelled in this particular area.

Here is the basic goal:

Get -Something | Filter | Change-Something | Save-Something

Basically, I want to avoid having to depend on methods on an object to perform my task:

Get -Something | %{ $_.DoSomething()} | %{$}

To be more specific, let’s say we have a Car Object class. This car has properties like make, model, color, tire count, size and type. It also has things it can do, like start, turn off, stop, turn, load and unload.

Using the developer approach, we can achieve this by creating a car class with the set properties and methods. This may seem simpler, but it’s not intuitive for your typical admin who does not want to do something like this:

Get -Car | ?{ $_. Type -eq "MiniVan"} | %{ $_.LoadPeople()} | %{ $_.Start()} | %{ $_.Turn( "Right")} | %{ $_.Stop()} | %{ $_.UnLoadPeople()}

From an Windows admin perspective, a bunch of task-oriented cmdlets would be your best bet. Let’s assume that instead of methods, you had these cmdlets:

  • Get-Car
  • New-Car
  • Remove-Car
  • Start-Car
  • Stop-Car
  • Invoke-TurnCar
  • Invoke-LoadCar
  • Invoke-UnLoadCar
  • Set-Car

You can now do something like this:

Get -Car - Type "MiniVan" | Invoke -LoadCar | Start -Car | Invoke -TurnCar -Right | Stop -Car | Invoke -UnloadCar

How simple is that? As you can see, it reads more like a sentence than script syntax.

I understand that PowerShell is powerful and includes objects that have methods, and it may seem like more work to provide each task with its own cmdlet. I also believe that it’s worth it. Whether you are an administrator or developer, as you expand your PowerShell skill set and write code for others’ consumption, remember to take the time to make it as intuitive as possible.

Miss a column? Check out our Scripting School archive.

You can follow on Twitter @WindowsTT.

Brandon Shell has been in the IT industry since 1994. He started out as a PC tech and general fix-it guy for numerous companies. In 2007, he joined the PowerShell MVP ranks, and Shell has spent the past several years building his PowerShell knowledge and helping others build theirs.

Dig Deeper on Windows administration tools

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.