Semua yang ingin Anda ketahui tentang ShouldProcess

  • Artikel

Fungsi PowerShell memiliki beberapa fitur yang sangat meningkatkan cara pengguna berinteraksi dengan mereka. Salah satu fitur penting yang sering diabaikan adalah -WhatIf dukungan dan -Confirm mudah ditambahkan ke fungsi Anda. Dalam artikel ini, kami mendalami cara mengimplementasikan fitur ini.

Catatan

Versi asli artikel ini muncul di blog yang ditulis oleh @KevinMarquette. Tim PowerShell berterima kasih kepada Kevin karena telah membagikan konten ini kepada kami. Silakan lihat blognya di PowerShellExplained.com.

Ini adalah fitur sederhana yang dapat Anda aktifkan dalam fungsi Anda untuk menyediakan jaring pengaman bagi pengguna yang membutuhkannya. Tidak ada yang lebih menakutkan daripada menjalankan perintah yang Anda tahu bisa berbahaya untuk pertama kalinya. Opsi untuk menjalankannya dapat -WhatIf membuat perbedaan besar.

CommonParameters

Sebelum kita melihat penerapan parameter umum ini , saya ingin melihat sekilas bagaimana parameter tersebut digunakan.

Menggunakan -WhatIf

Ketika perintah mendukung -WhatIf parameter , perintah ini memungkinkan Anda untuk melihat apa yang akan dilakukan perintah alih-alih membuat perubahan. ini adalah cara yang baik untuk menguji dampak perintah, terutama sebelum Anda melakukan sesuatu yang merusak.

PS C:\temp> Get-ChildItem
    Directory: C:\temp
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         4/19/2021   8:59 AM              0 importantfile.txt
-a----         4/19/2021   8:58 AM              0 myfile1.txt
-a----         4/19/2021   8:59 AM              0 myfile2.txt

PS C:\temp> Remove-Item -Path .\myfile1.txt -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".

Jika perintah mengimplementasikan ShouldProcessdengan benar , perintah tersebut akan menunjukkan kepada Anda semua perubahan yang akan dilakukannya. Berikut adalah contoh menggunakan kartubebas untuk menghapus beberapa file.

PS C:\temp> Remove-Item -Path * -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
What if: Performing the operation "Remove File" on target "C:\Temp\myfile2.txt".
What if: Performing the operation "Remove File" on target "C:\Temp\importantfile.txt".

Menggunakan -Confirm

Perintah yang mendukung -WhatIf juga mendukung -Confirm. Ini memberi Anda kesempatan mengonfirmasi tindakan sebelum melakukannya.

PS C:\temp> Remove-Item .\myfile1.txt -Confirm

Confirm
Are you sure you want to perform this action?
Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Dalam hal ini, Anda memiliki beberapa opsi yang memungkinkan Anda untuk melanjutkan, melewati perubahan, atau menghentikan skrip. Perintah bantuan menjelaskan masing-masing opsi seperti ini.

Y - Continue with only the next step of the operation.
A - Continue with all the steps of the operation.
N - Skip this operation and proceed with the next operation.
L - Skip this operation and all subsequent operations.
S - Pause the current pipeline and return to the command prompt. Type "exit" to resume the pipeline.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Pelokalan

Perintah ini dilokalkan di PowerShell sehingga bahasa berubah berdasarkan bahasa sistem operasi Anda. Ini adalah satu hal lagi yang dikelola PowerShell untuk Anda.

Beralih parameter

Mari kita luangkan waktu sejenak untuk melihat cara meneruskan nilai ke parameter pengalihan. Alasan utama saya memanggil ini adalah bahwa Anda sering ingin meneruskan nilai parameter ke fungsi yang Anda panggil.

Pendekatan pertama adalah sintaks parameter tertentu yang dapat digunakan untuk semua parameter tetapi Anda sebagian besar melihatnya digunakan untuk parameter pengalihan. Anda menentukan titik dua untuk melampirkan nilai ke parameter .

Remove-Item -Path:* -WhatIf:$true

Anda dapat melakukan hal yang sama dengan variabel.

$DoWhatIf = $true
Remove-Item -Path * -WhatIf:$DoWhatIf

Pendekatan kedua adalah menggunakan hashtable untuk memercikkan nilai.

$RemoveSplat = @{
    Path = '*'
    WhatIf = $true
}
Remove-Item @RemoveSplat

Jika Anda baru mengenal hashtable atau splatting, saya memiliki artikel lain tentang yang mencakup semua yang ingin Anda ketahui tentang hashtable.

MendukungShouldProcess

Langkah pertama untuk mengaktifkan -WhatIf dan -Confirm mendukung adalah menentukan SupportsShouldProcess dalam CmdletBinding fungsi Anda.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()
    Remove-Item .\myfile1.txt
}

Dengan menentukan SupportsShouldProcess dengan cara ini, kita sekarang dapat memanggil fungsi kita dengan -WhatIf (atau -Confirm).

PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".

Perhatikan bahwa saya tidak membuat parameter yang disebut -WhatIf. Menentukan SupportsShouldProcess secara otomatis membuatnya untuk kami. Ketika kita menentukan -WhatIf parameter pada Test-ShouldProcess, beberapa hal yang kita sebut juga melakukan -WhatIf pemrosesan.

Percayai tetapi verifikasi

Ada beberapa bahaya di sini yang mempercayai bahwa semua yang Anda sebut mewarisi -WhatIf nilai. Untuk contoh lainnya, saya akan berasumsi bahwa itu tidak berfungsi dan sangat eksplisit saat melakukan panggilan ke perintah lain. Saya sarankan Anda melakukan hal yang sama.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()
    Remove-Item .\myfile1.txt -WhatIf:$WhatIfPreference
}

Saya akan mengunjungi kembali nuansa banyak kemudian setelah Anda memiliki pemahaman yang lebih baik tentang semua bagian dalam bermain.

$PSCmdlet.ShouldProcess

Metode yang memungkinkan Anda untuk menerapkan SupportsShouldProcess adalah $PSCmdlet.ShouldProcess. Anda memanggil $PSCmdlet.ShouldProcess(...) untuk melihat apakah Anda harus memproses beberapa logika dan PowerShell mengurus sisanya. Mari kita mulai dengan contoh:

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    $file = Get-ChildItem './myfile1.txt'
    if($PSCmdlet.ShouldProcess($file.Name)){
        $file.Delete()
    }
}

Panggilan untuk $PSCmdlet.ShouldProcess($file.name) memeriksa -WhatIf (dan -Confirm parameter) kemudian menanganinya dengan sesuai. Penyebab -WhatIfShouldProcess output deskripsi perubahan dan pengembalian $false:

PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".

Panggilan menggunakan -Confirm jeda skrip dan meminta pengguna dengan opsi untuk melanjutkan. Ini mengembalikan $true jika pengguna memilih Y.

PS> Test-ShouldProcess -Confirm
Confirm
Are you sure you want to perform this action?
Performing the operation "Test-ShouldProcess" on target "myfile1.txt".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Fitur $PSCmdlet.ShouldProcess yang luar biasa adalah bahwa ia ganda sebagai output verbose. Saya sering bergantung pada ini saat menerapkan ShouldProcess.

PS> Test-ShouldProcess -Verbose
VERBOSE: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".

Overload

Ada beberapa kelebihan beban yang berbeda untuk $PSCmdlet.ShouldProcess dengan parameter yang berbeda untuk menyesuaikan olahpesan. Kami sudah melihat yang pertama dalam contoh di atas. Mari kita lihat lebih dekat.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    if($PSCmdlet.ShouldProcess('TARGET')){
        # ...
    }
}

Ini menghasilkan output yang mencakup nama fungsi dan target (nilai parameter).

What if: Performing the operation "Test-ShouldProcess" on target "TARGET".

Menentukan parameter kedua karena operasi menggunakan nilai operasi alih-alih nama fungsi dalam pesan.

## $PSCmdlet.ShouldProcess('TARGET','OPERATION')
What if: Performing the operation "OPERATION" on target "TARGET".

Opsi berikutnya adalah menentukan tiga parameter untuk mengkustomisasi pesan sepenuhnya. Ketika tiga parameter digunakan, yang pertama adalah seluruh pesan. Dua parameter kedua masih digunakan dalam -Confirm output pesan.

## $PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION')
What if: MESSAGE

Referensi parameter cepat

Untuk berjaga-jaga jika Anda datang ke sini hanya untuk mencari tahu parameter apa yang harus Anda gunakan, berikut adalah referensi cepat yang menunjukkan bagaimana parameter mengubah pesan dalam skenario yang berbeda -WhatIf .

## $PSCmdlet.ShouldProcess('TARGET')
What if: Performing the operation "FUNCTION_NAME" on target "TARGET".

## $PSCmdlet.ShouldProcess('TARGET','OPERATION')
What if: Performing the operation "OPERATION" on target "TARGET".

## $PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION')
What if: MESSAGE

Saya cenderung menggunakan yang dengan dua parameter.

ShouldProcessReason

Kami memiliki kelebihan beban keempat yang lebih maju daripada yang lain. Ini memungkinkan Anda untuk mendapatkan alasan ShouldProcess dijalankan. Saya hanya menambahkan ini di sini untuk kelengkapan karena kita hanya dapat memeriksa apakah $WhatIfPreference sebaliknya $true .

$reason = ''
if($PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION',[ref]$reason)){
    Write-Output "Some Action"
}
$reason

Kita harus meneruskan $reason variabel ke parameter keempat sebagai variabel referensi dengan [ref]. ShouldProcess diisi $reason dengan nilai None atau WhatIf. Saya tidak mengatakan ini berguna dan saya tidak punya alasan untuk menggunakannya.

Di mana menempatkannya

Anda menggunakan ShouldProcess untuk membuat skrip Anda lebih aman. Jadi Anda menggunakannya saat skrip Anda membuat perubahan. Saya ingin melakukan $PSCmdlet.ShouldProcess panggilan sedekat mungkin dengan perubahan.

## general logic and variable work
if ($PSCmdlet.ShouldProcess('TARGET','OPERATION')){
    # Change goes here
}

Jika saya memproses kumpulan item, saya menyebutnya untuk setiap item. Jadi panggilan akan ditempatkan di dalam perulangan foreach.

foreach ($node in $collection){
    # general logic and variable work
    if ($PSCmdlet.ShouldProcess($node,'OPERATION')){
        # Change goes here
    }
}

Alasan mengapa saya menempatkan ShouldProcess erat di sekitar perubahan, adalah bahwa saya ingin sebanyak mungkin kode untuk dijalankan ketika -WhatIf ditentukan. Saya ingin penyiapan dan validasi berjalan jika memungkinkan sehingga pengguna dapat melihat kesalahan tersebut.

Saya juga ingin menggunakan ini dalam tes Pester saya yang memvalidasi proyek saya. Jika saya memiliki sepotong logika yang sulit ditiru, saya sering dapat membungkusnya ShouldProcess dan menyebutnya dengan -WhatIf dalam tes saya. Lebih baik menguji beberapa kode Anda daripada yang lain.

$WhatIfPreference

Variabel preferensi pertama yang kita miliki adalah $WhatIfPreference. Ini $false secara default. Jika Anda mengaturnya ke $true maka fungsi Anda dijalankan seolah-olah Anda menentukan -WhatIf. Jika Anda mengatur ini dalam sesi Anda, semua perintah melakukan -WhatIf eksekusi.

Saat Anda memanggil fungsi dengan -WhatIf, nilai $WhatIfPreference diatur ke $true di dalam cakupan fungsi Anda.

ConfirmImpact

Sebagian besar contoh saya adalah untuk -WhatIf tetapi sejauh ini semuanya juga berfungsi untuk -Confirm meminta pengguna. Anda dapat mengatur ConfirmImpact fungsi ke tinggi dan meminta pengguna seolah-olah dipanggil dengan -Confirm.

function Test-ShouldProcess {
    [CmdletBinding(
        SupportsShouldProcess,
        ConfirmImpact = 'High'
    )]
    param()

    if ($PSCmdlet.ShouldProcess('TARGET')){
        Write-Output "Some Action"
    }
}

Panggilan ke Test-ShouldProcess ini melakukan -Confirm tindakan karena dampaknya High .

PS> Test-ShouldProcess

Confirm
Are you sure you want to perform this action?
Performing the operation "Test-ShouldProcess" on target "TARGET".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
Some Action

Masalah yang jelas adalah bahwa sekarang lebih sulit untuk digunakan dalam skrip lain tanpa meminta pengguna. Dalam hal ini, kita dapat meneruskan $false ke untuk -Confirm menekan prompt.

PS> Test-ShouldProcess -Confirm:$false
Some Action

Saya akan membahas cara menambahkan -Force dukungan di bagian selanjutnya.

$ConfirmPreference

$ConfirmPreference adalah variabel otomatis yang mengontrol ketika ConfirmImpact meminta Anda untuk mengonfirmasi eksekusi. Berikut adalah nilai yang mungkin untuk dan $ConfirmPreferenceConfirmImpact.

  • High
  • Medium
  • Low
  • None

Dengan nilai-nilai ini, Anda dapat menentukan tingkat dampak yang berbeda untuk setiap fungsi. Jika Anda telah $ConfirmPreference mengatur ke nilai yang lebih tinggi dari ConfirmImpact, maka Anda tidak diminta untuk mengonfirmasi eksekusi.

Secara default, $ConfirmPreference diatur ke High dan ConfirmImpact adalah Medium. Jika Anda ingin fungsi Anda secara otomatis meminta pengguna, atur ConfirmImpact ke High. Jika tidak, atur ke Medium jika merusak dan gunakan Low jika perintah selalu aman dijalankan dalam produksi. Jika Anda mengaturnya ke none, itu tidak meminta meskipun -Confirm ditentukan (tetapi masih memberi Anda -WhatIf dukungan).

Saat memanggil fungsi dengan -Confirm, nilai $ConfirmPreference diatur ke Low di dalam cakupan fungsi Anda.

Menekan permintaan konfirmasi berlapis

$ConfirmPreference bisa diambil oleh fungsi yang Anda panggil. Ini dapat membuat skenario di mana Anda menambahkan permintaan konfirmasi dan fungsi yang Anda panggil juga meminta pengguna.

Apa yang cenderung saya lakukan adalah menentukan -Confirm:$false pada perintah yang saya panggil ketika saya telah menangani permintaan.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    $file = Get-ChildItem './myfile1.txt'
    if($PSCmdlet.ShouldProcess($file.Name)){
        Remove-Item -Path $file.FullName -Confirm:$false
    }
}

Ini membawa kita kembali ke peringatan sebelumnya: Ada nuansa kapan -WhatIf tidak diteruskan ke fungsi dan ketika -Confirm diteruskan ke fungsi. Aku berjanji aku akan kembali ke ini nanti.

$PSCmdlet.ShouldContinue

Jika Anda membutuhkan lebih banyak kontrol daripada ShouldProcess yang disediakan, Anda dapat memicu perintah langsung dengan ShouldContinue. ShouldContinue$ConfirmPreferencemengabaikan , ConfirmImpact, -Confirm, $WhatIfPreference, dan -WhatIf karena meminta setiap kali dijalankan.

Sekilas, mudah untuk membingungkan ShouldProcess dan ShouldContinue. Saya cenderung ingat untuk digunakan ShouldProcess karena parameter dipanggil SupportsShouldProcess di CmdletBinding. Anda harus menggunakan ShouldProcess hampir setiap skenario. Itulah sebabnya saya membahas metode itu terlebih dahulu.

Mari kita lihat ShouldContinue dalam tindakan.

function Test-ShouldContinue {
    [CmdletBinding()]
    param()

    if($PSCmdlet.ShouldContinue('TARGET','OPERATION')){
        Write-Output "Some Action"
    }
}

Ini memberi kita perintah yang lebih sederhana dengan lebih sedikit opsi.

Test-ShouldContinue

Second
TARGET
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):

Masalah terbesar adalah ShouldContinue mengharuskan pengguna untuk menjalankannya secara interaktif karena selalu meminta pengguna. Anda harus selalu membangun alat yang dapat digunakan oleh skrip lain. Cara Anda melakukan ini adalah dengan menerapkan -Force. Aku akan mengunjungi kembali ide ini nanti.

Ya untuk semua

Ini secara otomatis ditangani dengan ShouldProcess tetapi kita harus melakukan sedikit lebih banyak pekerjaan untuk ShouldContinue. Ada kelebihan beban metode kedua di mana kita harus meneruskan beberapa nilai dengan referensi untuk mengontrol logika.

function Test-ShouldContinue {
    [CmdletBinding()]
    param()

    $collection = 1..5
    $yesToAll = $false
    $noToAll = $false

    foreach($target in $collection) {

        $continue = $PSCmdlet.ShouldContinue(
                "TARGET_$target",
                'OPERATION',
                [ref]$yesToAll,
                [ref]$noToAll
            )

        if ($continue){
            Write-Output "Some Action [$target]"
        }
    }
}

Saya menambahkan perulangan foreach dan koleksi untuk menunjukkannya dalam tindakan. Saya menarik ShouldContinue panggilan keluar dari if pernyataan untuk membuatnya lebih mudah dibaca. Memanggil metode dengan empat parameter mulai menjadi sedikit jelek, tetapi saya mencoba membuatnya terlihat sebersih yang saya bisa.

Menerapkan -Force

ShouldProcess dan ShouldContinue perlu menerapkan -Force dengan cara yang berbeda. Trik untuk implementasi ini adalah bahwa ShouldProcess harus selalu dijalankan, tetapi ShouldContinue tidak boleh dijalankan jika -Force ditentukan.

ShouldProcess -Force

Jika Anda mengatur ConfirmImpact ke high, hal pertama yang akan dicoba pengguna Anda adalah menekannya dengan -Force. Itu hal pertama yang kulakukan.

Test-ShouldProcess -Force
Error: Test-ShouldProcess: A parameter cannot be found that matches parameter name 'force'.

Jika Anda ingat dari bagian tersebut ConfirmImpact , mereka benar-benar perlu menyebutnya seperti ini:

Test-ShouldProcess -Confirm:$false

Tidak semua orang menyadari bahwa mereka perlu melakukan itu dan -Force tidak menekan ShouldContinue. Jadi kita harus menerapkan -Force untuk kewarasan pengguna kita. Lihat contoh lengkap ini di sini:

function Test-ShouldProcess {
    [CmdletBinding(
        SupportsShouldProcess,
        ConfirmImpact = 'High'
    )]
    param(
        [Switch]$Force
    )

    if ($Force -and -not $Confirm){
        $ConfirmPreference = 'None'
    }

    if ($PSCmdlet.ShouldProcess('TARGET')){
        Write-Output "Some Action"
    }
}

Kami menambahkan sakelar kami sendiri -Force sebagai parameter. Parameter -Confirm secara otomatis ditambahkan saat menggunakan SupportsShouldProcess di CmdletBinding.

[CmdletBinding(
    SupportsShouldProcess,
    ConfirmImpact = 'High'
)]
param(
    [Switch]$Force
)

Berfokus pada logika di -Force sini:

if ($Force -and -not $Confirm){
    $ConfirmPreference = 'None'
}

Jika pengguna menentukan -Force, kami ingin menekan prompt konfirmasi kecuali mereka juga menentukan -Confirm. Ini memungkinkan pengguna untuk memaksa perubahan tetapi masih mengonfirmasi perubahan. Kemudian kita mengatur $ConfirmPreference dalam cakupan lokal. Sekarang, menggunakan -Force parameter untuk sementara mengatur $ConfirmPreference ke tidak ada, menonaktifkan permintaan untuk konfirmasi.

if ($PSCmdlet.ShouldProcess('TARGET')){
        Write-Output "Some Action"
    }

Jika seseorang menentukan dan -Force-WhatIf, maka -WhatIf perlu diprioritaskan. Pendekatan ini mempertahankan -WhatIf pemrosesan karena ShouldProcess selalu dijalankan.

Jangan tambahkan pemeriksaan untuk nilai di $Force dalam if pernyataan dengan ShouldProcess. Itu adalah anti-pola untuk skenario spesifik ini meskipun itulah yang saya tunjukkan di bagian berikutnya untuk ShouldContinue.

ShouldContinue -Force

Ini adalah cara yang benar untuk menerapkan -Force dengan ShouldContinue.

function Test-ShouldContinue {
    [CmdletBinding()]
    param(
        [Switch]$Force
    )

    if($Force -or $PSCmdlet.ShouldContinue('TARGET','OPERATION')){
        Write-Output "Some Action"
    }
}

Dengan menempatkan di $Force sebelah kiri -or operator, operator akan dievaluasi terlebih dahulu. Menulisnya dengan cara ini mempersingkat eksekusi if pernyataan. Jika $force adalah $true, maka ShouldContinue tidak dijalankan.

PS> Test-ShouldContinue -Force
Some Action

Kita tidak perlu khawatir tentang -Confirm atau -WhatIf dalam skenario ini karena mereka tidak didukung oleh ShouldContinue. Inilah sebabnya mengapa perlu ditangani secara berbeda dari ShouldProcess.

Masalah cakupan

Menggunakan -WhatIf dan -Confirm seharusnya berlaku untuk semua yang ada di dalam fungsi Anda dan semua yang mereka sebut. Mereka melakukan ini dengan mengatur $WhatIfPreference ke $true atau mengatur $ConfirmPreference ke Low dalam cakupan lokal fungsi. Saat Anda memanggil fungsi lain, panggilan untuk ShouldProcess menggunakan nilai tersebut.

Ini benar-benar bekerja dengan benar sebagian besar waktu. Setiap kali Anda memanggil cmdlet bawaan atau fungsi dalam cakupan yang sama, cmdlet tersebut berfungsi. Ini juga berfungsi saat Anda memanggil skrip atau fungsi dalam modul skrip dari konsol.

Satu tempat tertentu di mana tidak berfungsi adalah ketika skrip atau modul skrip memanggil fungsi di modul skrip lain. Ini mungkin tidak terdengar seperti masalah besar, tetapi sebagian besar modul yang Anda buat atau tarik dari PSGallery adalah modul skrip.

Masalah intinya adalah bahwa modul skrip tidak mewarisi nilai untuk $WhatIfPreference atau $ConfirmPreference (dan beberapa lainnya) ketika dipanggil dari fungsi dalam modul skrip lainnya.

Cara terbaik untuk meringkas ini sebagai aturan umum adalah bahwa ini berfungsi dengan benar untuk modul biner dan tidak pernah mempercayainya untuk bekerja untuk modul skrip. Jika Anda tidak yakin, uji atau asumsikan tidak berfungsi dengan benar.

Saya pribadi merasa ini sangat berbahaya karena menciptakan skenario di mana Anda menambahkan -WhatIf dukungan ke beberapa modul yang bekerja dengan benar dalam isolasi, tetapi gagal bekerja dengan benar ketika mereka saling memanggil.

Kami memiliki GitHub RFC yang bekerja untuk memperbaiki masalah ini. Lihat Menyebarkan preferensi eksekusi di luar cakupan modul skrip untuk detail selengkapnya.

Dalam penutupan

Saya harus mencari cara menggunakan ShouldProcess setiap kali saya perlu menggunakannya. Butuh waktu lama untuk membedakan ShouldProcess dari ShouldContinue. Saya hampir selalu perlu mencari parameter apa yang akan digunakan. Jadi jangan khawatir jika Anda masih bingung dari waktu ke waktu. Artikel ini akan berada di sini ketika Anda membutuhkannya. Saya yakin saya akan sering mereferensikannya sendiri.

Jika Anda menyukai posting ini, silakan bagikan pemikiran Anda dengan saya di Twitter menggunakan tautan di bawah ini. Saya selalu suka mendengar dari orang-orang yang mendapatkan nilai dari konten saya.