Bagaimana cara saya mengelola debat teknis atas WCF vs Web API?

Saya mengelola tim yang terdiri dari 15 pengembang sekarang, dan kami terjebak pada suatu titik dalam memilih teknologi, di mana tim tersebut dibagi menjadi dua tim yang benar-benar berlawanan, memperdebatkan penggunaan WCF vs Web API.

Tim A yang mendukung penggunaan Web API, mengemukakan alasan-alasan berikut:

1. API Web hanyalah cara modern layanan penulisan ( Wikipedia )
2. WCF adalah overhead untuk HTTP. Ini solusi untuk TCP, dan Net Pipes, dan protokol lainnya
3. Model WCF bukan POCO, karena [DataContract] & [DataMember] dan atribut tersebut
4. SOAP tidak mudah dibaca dan berguna seperti JSON
5. SOAP adalah overhead untuk jaringan dibandingkan dengan JSON (transport over HTTP)
6. Tidak ada metode kelebihan beban

Tim B yang mendukung penggunaan WCF, mengatakan:

1. WCF mendukung banyak protokol (melalui konfigurasi)
2. WCF mendukung transaksi terdistribusi
3. Banyak contoh bagus dan kisah sukses ada untuk WCF (saat Web API masih muda)
4. Duplex sangat baik untuk komunikasi dua arah

Debat ini terus berlanjut, dan saya tidak tahu harus berbuat apa sekarang. Secara pribadi, saya pikir kita harus menggunakan alat hanya untuk tempat penggunaan yang tepat . Dengan kata lain, sebaiknya kita menggunakan Web API, jika kita ingin mengekspos layanan melalui HTTP, tetapi gunakan WCF ketika datang ke TCP dan Duplex.

Dengan mencari di internet, kita tidak bisa mendapatkan hasil yang solid. Banyak pos ada untuk mendukung WCF, tetapi sebaliknya kami juga menemukan keluhan orang tentang itu. Saya tahu bahwa sifat dari pertanyaan ini mungkin terdengar dapat diperdebatkan, tetapi kita perlu beberapa petunjuk yang baik untuk memutuskan. Kita terjebak pada suatu titik di mana memilih teknologi secara kebetulan mungkin membuat kita menyesal nanti. Kami ingin memilih dengan mata terbuka.

Penggunaan kami sebagian besar untuk web, dan kami akan mengekspos layanan kami melalui HTTP. Dalam beberapa kasus (misalnya 5 hingga 10 persen) kita mungkin perlu transaksi terdistribusi.

Apa yang harus saya lakukan sekarang? Bagaimana cara saya mengelola debat ini dengan cara yang konstruktif?

Ketika kedua belah pihak memiliki argumen yang baik dan pendapat tentang masalah tersebut terlalu kuat untuk mencapai konsensus, Anda sebagai manajer perlu membuat keputusan dan mengakhiri perdebatan. Kalau tidak, itu hanya akan berputar-putar dan memperkuat posisi semua peserta bahkan lebih. Semakin lama Anda menunggu, semakin sulit bagi pihak yang "kalah" untuk mengakui kekalahan dan bekerja secara produktif dengan hasilnya.

Tuliskan semua argumen, nilai kepentingannya untuk proyek, dan kemudian buat keputusan Anda. Ketika Anda tidak bisa, balikkan koin. Proyek Anda kemungkinan besar dapat diselesaikan dengan teknologi baik, dan membuang-buang waktu yang berharga dengan debat yang tidak perlu hanya akan menghabiskan uang yang tidak perlu.

Dengan asumsi kedua belah pihak 100% benar dalam semua argumen mereka, yang mana yang penting?

Model WCF bukan POCO, karena [DataContract] & [DataMember] dan atribut tersebut

Apakah kamu peduli? Apakah Anda berencana melakukan sesuatu yang memerlukan POCO?

WCF mendukung transaksi terdistribusi

Sekali lagi apakah ini sesuatu yang akan Anda gunakan dan perlu membangun jika Anda tidak memilikinya karena Anda mengambil jalan lain?

Pada dasarnya sampai ke jantung yang mana:

• Menawarkan semua yang Anda butuhkan (Jika tidak menawarkan semua yang Anda butuhkan yang membuat Anda harus melakukan pekerjaan paling sedikit).
• Menawarkan jumlah sampah paling sedikit yang tidak akan Anda gunakan tetapi tetap harus menerima.

Setiap argumen yang diajukan yang tidak sesuai dengan apa yang perlu Anda capai tidak relevan dan tidak boleh menjadi faktor dalam keputusan Anda, dengan beberapa ruang gerak untuk mempertimbangkan ekspansi di masa depan.

Masukkan dua sen saya.

Sebagai seorang manajer, Anda harus meminta rekan tim Anda untuk mengingat prinsip Yagni . Ini akan membantu mengurangi daftar alasan yang diajukan oleh kedua Tim.

Penggunaan kami sebagian besar untuk web, dan kami akan mengekspos layanan kami melalui HTTP. Dalam beberapa kasus (misalnya 5 hingga 10 persen) kita mungkin perlu transaksi terdistribusi.

Daripada menyelami transaksi yang didistribusikan, Anda harus mempertimbangkan bekerja dengan kompensasi sebagai gantinya.

Hal terakhir yang harus diperhatikan adalah kurva belajar. Bergantung pada tenggat waktu proyek Anda, sebagai manajer, Anda harus dapat memutuskan apakah boleh mulai mempelajari teknologi baru atau tidak.

Jika Anda punya banyak waktu untuk dihabiskan, maka pergilah untuk semacam Hari Inovasi di mana Tim A dan B akan memiliki satu hari untuk menghasilkan bukti konsep berdasarkan persyaratan yang sama.

Ngomong-ngomong, kepada orang yang mengatakan " model WCF bukan POCO, karena [DataContract] & [DataMember] dan atribut-atribut itu ", katakan padanya bahwa POCO pada umumnya dimaksudkan untuk menjadi entitas domain dan bahwa itu bukan praktik terbaik untuk mengekspos objek domain Anda ke klien jenis apa pun, inilah tujuan DTO.

Apa yang harus saya lakukan sekarang? Bagaimana cara saya mengelola debat ini dengan cara yang konstruktif?

Pertama, jauhkan subjektivitas. Dalam argumen tim WebAPI Anda, saya menemukan "API Web hanya cara modern" *, "model WCF bukan POCO, karena atribut-atribut itu" dan "SOAP tidak dapat dibaca dan berguna seperti JSON" cukup berargumen, cukup berpendirian, jika tidak salah , dan tidak akan membantu membuat keputusan.

Jadi, apa yang harus dilakukan: putuskan apa yang ingin Anda lakukan dengan layanan Anda , lalu pilih teknik yang mengakomodasi tujuan itu dan pemeliharaannya dan ekstensibilitasnya dengan jumlah rasa sakit yang paling sedikit. Anda dapat melakukan ini hanya dengan meneliti apakah ada aspek yang didukung oleh kerangka kerja yang digunakan.

Bahan bacaan yang menarik:

• Mvc 4 vs. Wcf Web Api
• API Web WCF atau ASP.NET? Dua sen saya pada subjek
• WebAPI atau WCF?

*: perhatikan Anda merujuk ke Wikipedia untuk ini, di mana kutipannya adalah: " Aplikasi web Web 2.0 telah pindah dari arsitektur berorientasi layanan (SOA) dengan layanan web berbasis SOAP menuju koleksi yang lebih kohesif dari sumber daya web yang tenang" . Itu adalah contoh penggunaan ketika layanan Anda akan dikonsumsi dari halaman web. Ini juga dapat dengan mudah dilakukan dengan WCF, menggunakan WebHttpBinding. Itu tidak mengatakan "Gunakan WebAPI untuk ini" .

Jika pertanyaan ini melampaui "bagaimana mengelola diskusi" : Saya akan menggunakan WCF jika layanan tersebut akan dikonsumsi oleh non-web-klien, karena metadata-nya memungkinkan untuk generasi klien yang sangat mudah diketik dengan sangat baik.

Selain manajemen tim, Anda tidak memilih yang satu dari yang lain. Anda perlu melihat tujuan dari setiap layanan web dan menggunakan teknologi yang sesuai untuk bagian spesifik aplikasi. Ini seperti melarang prosedur toko ketika tim menggunakan kerangka kerja entitas.

Penggunaan kami sebagian besar untuk web, dan kami akan mengekspos layanan kami melalui HTTP. Dalam beberapa kasus (misalnya 5 hingga 10 persen) kita mungkin perlu transaksi terdistribusi.

Kemudian Anda menulis 5 ~ 10% layanan web di WCF. Jika layanan ini akan dirujuk secara internal di proyek lain, tidak ada perdebatan. Keuntungan dari kemampuan untuk mengimpor kontrak WCF untuk membuat proxy klien TIDAK terbuka untuk diskusi. Dibutuhkan seluruh integrasi, efisiensi, dan keamanan jenis ke tingkat yang sama sekali baru.

Anda menulis apa yang akan digunakan untuk permintaan api publik (mungkin) / Ajax di api web Asp.net.

Jika hanya panggilan halaman khusus ajax, Anda bisa menggunakan Asp.Net MVC.

Jangan memilih, merangkul mereka semua. Api web WCF dan Asp.net melayani berbagai tujuan. Tidak ada yang mengatakan Anda tidak dapat memiliki apel dan jeruk di salad buah Anda. Mencoba memilih satu dari yang lain dan menekannya setiap skenario hanyalah kemalasan belaka.

Tim kami melakukan diskusi serupa beberapa bulan yang lalu. Faktor penentu bagi kami adalah bagaimana kami akan menciptakan dan menerapkan setiap teknologi. Karena kami sudah membangun aplikasi MVC dan menggunakan Knockout.js untuk pengikatan data, kami secara efektif menggunakan MVVM dengan pengontrol yang hanya menjadi API untuk data.

Ini memungkinkan kami untuk mengkategorikan penggunaan teknologi oleh kami dengan proyek ini sebagai berikut:

• Web API akan digunakan sebagai API kami untuk panggilan knockout dan Ajax, menjadikannya perintah kami untuk pola MVVM. Logika bisnis kami untuk aplikasi web dibungkus di belakang lapisan ini melalui sejumlah kelas dan repositori dan pabrik.
• WCF kemudian digunakan untuk penyimpanan data kami, memaparkan data dari basis data kami tidak hanya untuk situs web ini, juga sedikit untuk situs atau layanan lain yang mengonsumsi data yang terbuka.

Meskipun ini mungkin bukan respons teknis populer atau hiper, menentukan apa yang Anda butuhkan terlebih dahulu dan bagaimana atau apakah teknologi akan membantu adalah apa yang membantu tim saya memutuskan teknologi mana yang akan digunakan.

Dengan kata lain, sebaiknya kita menggunakan Web API, jika kita ingin mengekspos layanan melalui HTTP, tetapi gunakan WCF ketika datang ke TCP dan Duplex.

Itu akan menjadi pendekatan yang paling masuk akal. Sangat umum untuk memiliki layanan WCF dan WebApi di aplikasi web yang sama di mana keduanya melayani tujuan yang berbeda.

Hanya untuk memperbaiki beberapa argumen:

Model WCF bukan POCO, karena [DataContract] & [DataMember] dan atribut tersebut

Dalam banyak kasus model WCF bekerja tanpa datacontract / atribut datamember.

SOAP tidak mudah dibaca dan berguna seperti JSON

Memang tidak benar, tetapi layanan web WCF biasanya membawa XML biasa daripada SOAP yang membengkak. Ini jelas bisa dibaca.

Satu argumen untuk WCF: jika ada WSDL tersedia, ada banyak alat di hampir semua teknologi yang dapat membuat proksi dari metadata. Di sisi lain, Skema JSON belum semuanya didukung secara luas.

Mengapa tidak berjalan sesuai dengan Layanan Data WCF? pertanyaan gaya OData / webapi bagus dan kegunaan dengan kekuatan WCF, dan kemampuan untuk kembali dengan JSONbaik. Wcf juga tidak terlalu buruk jika Anda memiliki kode hosting wcf otomatis yang bagus seperti berikut:

https://github.com/ImaginaryDevelopment/MvcOdata

Saya akan mengatakan mereka tidak terpisah sama sekali, kecuali bahwa ketika kami pergi untuk menggunakan WebApidi ujung depan dan WCF data servicesdi tingkat menengah, WebApimuntah pada hal-hal sederhana seperti string berisi atau string yang cocok dengan operator odata.

Arsitek yang baik menunda keputusan teknologi sampai mereka benar-benar perlu untuk membuat.

Dengan kata lain, jangan membuat keputusan sampai klien benar-benar perlu terhubung. Anda dapat membangun lapisan layanan yang sepenuhnya teruji tanpa benar-benar meletakkan mekanisme transportasi / komunikasi di atasnya. 95% pekerjaan dapat dilakukan "di bawah" adaptor, di luar kerangka kerja.

Tiba saatnya untuk mengekspos layanan-layanan tersebut kepada klien jarak jauh, Anda dapat memilih kerangka kerja paling trendi dari rak dan menulis bungkus tipis di atas lapisan layanan serbaguna.

Sial, jika lapisan layanan "nyata" Anda dilakukan dengan baik, Anda bahkan dapat mencoba beberapa pembungkus dengan biaya minimal.

Lagipula itulah jawaban dogmatis. Dalam prakteknya , Anda mungkin ingin memilih yang paling sederhana alat dari rak untuk memfasilitasi awal dan sering tes integrasi - tapi, masih membatasi ketergantungan Anda pada hal itu dan memperlakukannya secara ketat sebagai hanya lapisan komunikasi tipis di atas nyata layanan.

Jika Anda mengambil pendekatan ini, Anda mungkin akan menemukan bahwa Anda memilih alat paling sederhana untuk digunakan pada awalnya dan tidak ada yang akan ribut , karena tim tahu mereka dapat mengimplementasikan alat atau kerangka kerja yang lebih canggih atau trendi nanti, jika perlu , dengan upaya minimal.

Karenanya saya menghadapi pilihan yang sama sekarang, saya bertanya pada diri sendiri apa bagian dari fitur dari WCF yang digunakan tim kami saat ini. Apakah kita menggunakan protokol yang berbeda? Tidak. Apakah kita menggunakan dukungan transaksi? Tidak (walaupun kami menggunakan mekanisme konsistensi akhirnya yang dapat disesuaikan) Apakah kita menggunakan duplex? Tidak.

Mengapa kami ingin menggunakan API Web? Integrasi frontend yang lebih mudah (menghapus lapisan layanan tambahan yang ada sekarang), SignalR untuk mendorong balasan ke klien, caching untuk GET.

Mungkin, orang bisa menemukan alasan lain :) Juga, alasan untuk tetap dengan WCF.

Jika saya berada di posisi Anda, saya akan mulai dengan memeriksa kemampuan tim Anda. Jika semua orang di tim Anda sudah tahu WCF dan hanya sebagian kecil yang tahu Web API maka keputusan Anda sudah dibuat untuk Anda.

Dengan segala cara jika Anda punya waktu kemudian berinvestasi dalam belajar dan meningkatkan basis pengetahuan Anda, tetapi tidak dengan mengorbankan kebutuhan bisnis dan produktivitas perusahaan.

Saya akan bertanya model interaksi apa yang perlu Anda dukung? Apakah antarmuka eksternal yang Anda inginkan lebih menyerupai RPC atau REST? Dalam pengalaman saya itu biasanya di suatu tempat antara tetapi kebanyakan satu atau yang lain.

Apakah Anda menggunakan layanan Anda sendiri untuk proyek-proyek lain di .Net? Ini mungkin satu-satunya pertanyaan paling terbuka yang bisa Anda tanyakan. WCF memang memiliki keuntungan untuk dapat mengabstraksi antarmuka Anda menjadi perpustakaan kelas yang terpisah dan dapat membangun dan menyuntikkan klien Anda. Sebagai perpanjangan untuk ini, Anda dapat me-mount proyek berbasis WCF Anda dengan JSON dan SOAP / WSDL endpoint, saya sudah melakukannya. WCF juga menawarkan jaminan yang lebih baik terhadap antarmuka yang Anda tentukan.

Yang mengatakan, jika Anda berharap memiliki klien dari platform lain XML secara umum, apalagi SOAP memiliki overhead yang dapat diukur melampaui apa yang dimiliki JSON titik akhir sederhana. Jika Anda menggunakan rute JSON / Web API, maka Anda harus menjadi jauh lebih baik dalam mendokumentasikan cara berinteraksi dengan titik akhir dan API Anda.

Secara umum, saya akan menyarankan menulis dokumen API sederhana yang menyatakan bagaimana Anda akan mengirimkan data, dan bagaimana Anda menginginkan respons untuk struktur objek permintaan tunggal. Tulis test case Anda dengan cara yang paling universal, dan dokumentasikan seperti itu. Saya akan merekomendasikan pernyataan ikal sederhana. Kemudian mintalah beberapa anggota Anda menerapkan ini menggunakan WCF dan dengan Web API. Lalu lihat mana yang menang.

Secara pribadi, meskipun telah melakukan beberapa proyek yang relatif besar dan implementasi dengan WCF, saya sebenarnya condong ke implementasi paling sederhana yang dalam pikiran saya sebenarnya adalah WCF lurus dengan menggunakan hasil JSON dan beberapa perilaku override di Global.asax.cs untuk menangani kondisi kesalahan. Jika dokumentasi API menyertakan pernyataan ikal, dan Anda dapat menggunakan semua fungsionalitas API Anda dengan contoh ikal, menjadi lebih mudah bagi klien untuk diimplementasikan dalam bahasa apa pun yang mendukung antarmuka web. Di sinilah WCF mulai jatuh. Memiliki API yang terdefinisi dengan baik dengan dokumentasi agnostik lebih baik daripada memiliki struktur dengan perkakas otomatis ketika berhadapan dengan sistem asing. Berbicara sebagai konsumen sistem tersebut dari platform lain.

Satu hal di luar itu, adalah mengimplementasikan klien Anda dalam dua bahasa yang berbeda. Lakukan klien di C #, tetapi juga lakukan di Node.js atau Python dan lihat seberapa baik mereka benar-benar cocok. Latihan itu sendiri akan membantu Anda menghilangkan ujung yang longgar di API Anda.