Kapan menggunakan Windows Workflow Foundation? [Tutup]

Beberapa hal lebih mudah diimplementasikan hanya dengan tangan (kode), tetapi beberapa lebih mudah melalui WF. Sepertinya WF dapat digunakan untuk membuat (hampir) algoritma apa pun. Jadi (secara teoritis) saya dapat melakukan semua logika saya di WF, tetapi mungkin ide yang buruk untuk melakukannya untuk semua proyek.

Dalam situasi apa itu ide yang baik untuk menggunakan WF dan kapan akan membuat hal-hal lebih sulit maka mereka harus? Apa pro dan kontra / biaya WF vs coding dengan tangan?

Anda mungkin perlu WF hanya jika salah satu dari yang berikut ini benar:

1. Anda memiliki proses yang berjalan lama.
2. Anda memiliki proses yang sering berubah.
3. Anda menginginkan model visual dari proses tersebut.

Untuk detail lebih lanjut, lihat posting Paul Andrew: Untuk apa menggunakan Windows Workflow Foundation?

Tolong jangan bingung atau menghubungkan WF dengan pemrograman visual apa pun. Itu salah dan dapat menyebabkan keputusan arsitektur / desain yang sangat buruk.

Tidak pernah. Anda mungkin akan menyesalinya:

• Curam kurva pembelajaran
• Sulit di-debug
• Sulit dipertahankan
• Tidak memberikan daya, fleksibilitas, atau peningkatan produktivitas yang cukup untuk membenarkan penggunaannya
• Dapat dan akan merusak status aplikasi yang tidak dapat dipulihkan

Satu-satunya waktu saya bisa membayangkan menggunakan WF adalah jika saya ingin meng-host desainer untuk pengguna akhir dan mungkin bahkan tidak.

Percayalah, tidak ada yang akan sesederhana itu, sekuat, atau sefleksibel kode yang Anda tulis untuk melakukan persis apa yang Anda perlukan. Tinggal jauh dari WF.

Tentu saja, ini hanya pendapat saya, tapi saya pikir itu bagus sekali. :)

Kode yang dihasilkan oleh WF tidak baik. Nilai yang dibawa oleh WF adalah dalam representasi visual dari sistem, meskipun saya belum melihat apa-apa (6-7 proyek sedang bekerja dengan WF yang telah saya ikuti) di mana saya tidak akan lebih suka proyek kode tangan yang lebih sederhana .

Secara umum, jika Anda tidak memerlukan fitur ketekunan dan pelacakan (yang menurut saya adalah fitur utama), Anda tidak harus menggunakan Workflow Foundation.

Berikut ini kelebihan dan kekurangan Workflow Foundation yang saya kumpulkan dari pengalaman saya:

Keuntungan

• Kegigihan: Jika Anda akan memiliki banyak proses yang berjalan lama (pikirkan hari, minggu, bulan), maka Alur kerja sangat bagus untuk ini. Contoh alur kerja menganggur tetap ke database sehingga tidak menggunakan memori.
• Pelacakan: WF menyediakan mekanisme untuk melacak setiap aktivitas yang dieksekusi dalam alur kerja
• * Desainer Visual: Saya menempatkan ini sebagai *, karena saya pikir ini benar-benar hanya berguna untuk tujuan pemasaran. Sebagai seorang pengembang, saya lebih suka menulis kode daripada menjepret semuanya secara visual. Dan ketika Anda memiliki alur kerja non-pengembang membuat, Anda sering berakhir dengan kekacauan besar yang membingungkan.

Kekurangan

• Model Pemrograman: Anda benar-benar terbatas dalam fitur pemrograman. Pikirkan semua fitur hebat yang Anda miliki di C #, lalu lupakan. Pernyataan satu atau dua baris sederhana dalam C # menjadi kegiatan blok yang cukup besar. Ini sangat menyebalkan untuk validasi input. Karena itu, jika Anda benar-benar berhati-hati untuk hanya menjaga logika tingkat tinggi dalam alur kerja, dan segala sesuatu yang lain dalam C #, maka itu mungkin tidak menjadi masalah.
• Kinerja: Alur kerja menghabiskan banyak memori. Jika Anda menggunakan banyak alur kerja di server, pastikan Anda memiliki banyak memori. Perlu diketahui juga bahwa alur kerja jauh lebih lambat daripada kode C # normal.
• Curam kurva curam, sulit di-debug: Seperti disebutkan di atas. Anda akan menghabiskan banyak waktu mencari tahu cara menyelesaikan pekerjaan, dan mencari cara terbaik untuk melakukan sesuatu.
• Ketidakcocokan Versi Alur Kerja: Jika Anda menggunakan alur kerja dengan ketekunan, dan Anda perlu melakukan pembaruan pada alur kerja, instance alur kerja lama tidak lagi kompatibel. Seharusnya ini diperbaiki di .NET 4.5.
• Anda harus menggunakan ekspresi VB (.NET 4.5 memungkinkan untuk ekspresi C #).
• Tidak fleksibel: Jika Anda memerlukan beberapa fungsionalitas khusus atau spesifik yang tidak disediakan oleh Workflow Foundation, bersiaplah untuk banyak rasa sakit. Dalam beberapa kasus, itu bahkan mungkin tidak mungkin. Siapa yang tahu sampai Anda mencobanya? Ada banyak risiko di sini.
• Layanan WCF XAML tanpa antarmuka: Biasanya dengan layanan WCF, Anda berkembang melawan antarmuka. Dengan Layanan XAML WCF, Anda tidak dapat memastikan Layanan XAML WCF telah mengimplementasikan semuanya dalam sebuah antarmuka. Anda bahkan tidak perlu mendefinisikan antarmuka. (sejauh yang aku tahu...)

Alasan utama yang saya temukan untuk menggunakan fondasi alur kerja adalah seberapa banyak itu membawa Anda keluar dari kotak dalam hal pelacakan dan ketekunan. Sangat mudah untuk mendapatkan layanan ketekunan dan berjalan, yang menghadirkan keandalan dan distribusi beban antara banyak instance dan host.

Di sisi lain, sama seperti formulir aplikasi, pola kode yang mendorong Anda ke arah workflow buruk. Tetapi Anda dapat menghindari masalah dengan menulis kode di alur kerja dan mendelegasikan semua pekerjaan ke kelas lain, yang dapat diatur dan unit diuji lebih anggun daripada alur kerja. Kemudian Anda mendapatkan aspek visual keren dari desainer tanpa sedikitpun kode spaghetti di belakang.

Secara pribadi, saya tidak dijual di WF. Bagi saya manfaatnya tidak sejelas teknologi MS baru lainnya, seperti WPF atau WCF.

Saya pikir WF akan banyak digunakan dalam aplikasi bisnis di masa depan, tetapi saya tidak punya rencana untuk menggunakannya karena sepertinya alat yang tepat untuk pekerjaan untuk proyek saya tidak ada.

Perusahaan saya saat ini bekerja untuk mendirikan Windows Workflow Foundation (WF) dan alasan mereka memilih untuk menggunakannya adalah karena aturan akan sering berubah dan itu akan memaksa mereka untuk melakukan kompilasi ulang berbagai dll dll dan solusi mereka adalah untuk menempatkan aturan di DB dan memanggilnya dari sana. Dengan cara ini mereka dapat mengubah aturan dan tidak perlu mengkompilasi ulang dan mendistribusikan kembali dll.

Windows Workflows merayu manajer TI non-coding, BA dan sejenisnya seperti halnya sepupunya BizTalk tetapi dalam pengujian unit praktik, debugging dan cakupan kode hanyalah tiga dari banyak jebakan. Anda dapat mengatasi beberapa dari mereka tetapi Anda harus berinvestasi dalam mencapai itu sedangkan dengan kode sederhana Anda baru saja mendapatkannya. Jika Anda benar-benar memiliki persyaratan jangka panjang maka Anda mungkin perlu sesuatu yang lebih canggih. Saya telah mendengar argumen tentang kemampuan untuk meletakkan file xaml baru ke dalam produksi tanpa mengkompilasi ulang dll. Tapi jujur ​​waktu yang Workflow akan mengkonsumsi dapat lebih baik digunakan untuk meningkatkan Integrasi Berkelanjutan Anda ke titik di mana penyebaran yang dikompilasi tidak menjadi masalah.

Saya akan menggunakannya di lingkungan di mana saya harus bekerja dengan alur kerja, namun ketika menggunakannya bersamaan dengan K2 atau bahkan SharePoint 2007, kekuatan platform sangat berguna. Ketika mengembangkan aplikasi bisnis dengan spesialis BI penggunaan platform direkomendasikan dan ini biasanya hanya relevan untuk merampingkan dan meningkatkan proses bisnis.

Sebagai catatan, WF dikembangkan bersama dengan tim pengembangan K2 dan Blackpearl K2 baru dibangun di atas WF, demikian juga mesin alur kerja MOSS 2007 dan WSS 3.0.

Ketika Anda tidak ingin secara manual menulis semua kode untuk mempertahankan antarmuka visual, pelacakan dan ketekunan, itu adalah pilihan bijak untuk memilih WF.

Saya telah menggunakan alur kerja Windows selama berbulan-bulan sekarang untuk mengembangkan kegiatan khusus dan perancang ulang yang di-host yang dapat digunakan non-pengembang untuk membangun alur kerja. WF sangat kuat tetapi hanya sebagus aktivitas kustom yang dibangun oleh pengembang. Ketika sampai pada itu, seorang pengembang harus melihat alur kerja yang dibangun oleh non-pengembang untuk menguji dan men-debug tetapi dari titik itu mereka dapat membuat aliran kerja konsep - yang fantastis.

Selain itu, dalam kasus di mana Anda memiliki proses yang berjalan lama WF adalah tumpukan teknologi yang baik untuk digunakan ketika Anda perlu memperbarui proses secara dinamis - tanpa harus menginstal ulang / mengunduh atau melakukan apa pun, cukup tambahkan file XAML baru ke direktori dan arsitektur Anda harus atur dengan versi untuk menghapus yang lama dan gunakan yang baru.