Layanan Data WCF (OData) Vs ASP.NET Web API

Saya merancang aplikasi terdistribusi yang akan terdiri dari layanan RESTful dan berbagai klien (Silverlight, iOS, Windows Phone 7, dll). Saat ini saya sedang menentukan teknologi mana yang harus saya gunakan untuk mengimplementasikan layanan saya, WCF Data Services (OData) atau ASP.NET Web API baru yang keluar dengan ASP.NET MVC 4.

Saya telah menyaksikan beberapa presentasi online tentang masing-masing dan sekarang saya condong ke Layanan Data WCF terutama karena mekanisme penyaringan yang dibangun ke dalam URI dan kemampuan hypermedia asli. Satu-satunya downside yang bisa saya lihat adalah verbositas spesifikasi Atom Pub sebagai lawan POX.

Adakah yang harus saya ketahui tentang kedua teknologi ini sebelum membuat keputusan? Mengapa seseorang memilih ASP.NET Web API daripada WCF Data Services?

Ini adalah pertanyaan subjektif, jadi inilah jawaban subjektifnya. IMO, WCF memiliki terlalu banyak overhead untuk layanan RESTful sederhana. API Web, di sisi lain, dirancang khusus untuk layanan RESTful.

Saya setuju dengan Dave Ward dalam hal ini . Lihat blognya untuk informasi lebih lanjut.

Saya sudah lama bertahan melawan tekanan untuk pindah dari ASMX ke WCF dalam proyek WebForms, karena menerima kompleksitas WCF terutama hanya memberi saya penghargaan dengan serialisasi JSON yang kurang fleksibel. Sebaliknya, saya telah mulai mengubah beberapa proyek saya dari ASMX ke Web API, dan senang dengan betapa mudahnya Web API menggantikan ASMX.

Saya yakin Microsoft akhirnya menemukan keseimbangan yang baik antara kesederhanaan ASMX dan kekuatan WCF dengan API Web.

Saat ini terdapat perbedaan besar lainnya antara WebApi dan Layanan Data WCF, yang sepertinya tidak pernah disebutkan oleh siapa pun. Saya berharap MS akan menghasilkan artikel bagus yang membandingkan keduanya.

Saya telah mengikuti OData untuk beberapa waktu dan juga WebApi. Saya selalu menemukan beberapa perbedaan utama.

Pertama, saya tidak yakin apa yang dimaksud bos Anda dengan "MS mendukung WebApi", yang berarti mereka tidak mendukung OData ?? IMO, mereka mendukung keduanya dan saat ini ada sedikit tumpang tindih. Pasar Data Azure Windows memaparkan datanya menggunakan OData, Penyimpanan Tabel Azure menggunakan OData, SharePoint 2010 memungkinkan Kueri OData melalui Datanya, dan Produk lain dari MS juga mendukungnya, seperti Excel PowerPivot. Ini adalah kerangka kerja Kueri yang sangat kuat dalam hal Data relasional. Dan karena RESTful, bahasa, kerangka kerja, perangkat, dll. Dapat berintegrasi dengannya.

Inilah yang saya suka tentang OData + WCF Data Services:

Layanan Data OData + WCF akhirnya memungkinkan Aplikasi Klien menjadi lebih "ekspresif" saat menanyakan Data melalui Web. Sebelumnya, kami selalu harus menggunakan ASMX atau WCF untuk membangun API Web kaku yang menjadi berat dan memerlukan perubahan konstan setiap kali UI menginginkan sesuatu yang sedikit berbeda. Aplikasi Klien hanya dapat menentukan parameter untuk menentukan kriteria apa yang akan dikembalikan. Atau lakukan seperti yang saya lakukan dan "Serialisasi" LINQ Expressions dan berikan itu sebagai Parameter dan hidrat ulang ke Expressions<Func<T,bool>>dalam Server. Itu layak. Menyelesaikan pekerjaan, tetapi saya ingin menggunakan LINQ pada Klien dan menerjemahkannya melalui Web menggunakan REST, yang persis seperti yang diizinkan oleh OData dan saya tidak ingin menggunakan solusi "hack" saya sendiri.

Ini seperti mengekspos "TRANSACT SQL" tanpa membutuhkan DB Connection String. Cukup berikan Url dan whoala! Mulailah membuat kueri. Tentu saja, WebApi dan Layanan Data WCF mendukung Autentikasi / Otorisasi, sehingga Anda dapat mengontrol akses, menambahkan pernyataan "Di mana" tambahan berdasarkan peran atau konfigurasi data lainnya. Saya lebih suka melakukan ini di Lapisan Api Web saya daripada di SQL (seperti membuat Tampilan atau Penyimpanan Procs). Dan sekarang Aplikasi dapat membuat kueri sendiri, Anda akan melihat alat Pelaporan Ad-Hoc dan BI mulai memanfaatkan OData dan memungkinkan Pengguna untuk menentukan hasil mereka sendiri. Tidak mengandalkan Laporan Statis di mana mereka memiliki kontrol minimal.

Saat mengembangkan di Silverlight, Windows 8 Metro, atau ASP.NET (MVC, WebForms, dll), Anda cukup menambahkan "Referensi Layanan" di Visual Studio ke Layanan Data WCF dan dengan cepat mulai menggunakan LINQ untuk meminta Data DAN Anda mendapatkan "Konteks Data" pada Klien, yang artinya melacak perubahan dan memungkinkan Anda untuk "Mengirimkan" perubahan Anda secara atomis kembali ke Server. Ini sangat mirip dengan Layanan RIA untuk Silverlight. Saya akan menggunakan Layanan Data WCF daripada Layanan RIA, tetapi pada saat itu, layanan tersebut tidak mendukung DataAnnotations atau Actions, tetapi sekarang mendukungnya :) Layanan Data WCF memiliki keunggulan lain dibandingkan Layanan RIA, yaitu kemampuan untuk melakukan "Proyeksi" dari Klien. Ini dapat membantu kinerja, jika saya tidak ingin mengembalikan semua Properti dari Entitas. Memiliki "Konteks Data"

Jadi, Layanan Data WCF sangat bagus jika Anda memiliki Data dengan hubungan, terutama jika Anda menggunakan SQL Server dan Entity Framework. Anda akan dengan cepat dapat mengekspos Data + Tindakan yang Dapat Di-Quer (panggilan untuk menjalankan operasi, yaitu alur kerja, proses latar belakang) melalui REST dengan Kode yang sangat sedikit. Layanan Data WCF baru saja diperbarui. Rilis baru diluncurkan. Lihat semua fungsi baru.

Kelemahan dari Layanan Data WCF adalah "kontrol" yang Anda lepas atas HTTP Stack. Saya menemukan kelemahan terbesar adalah pada IQueryable<T>Metode yang mengembalikan Koleksi. Tidak seperti Layanan RIA DAN WebApi, Anda TIDAK memiliki akses penuh untuk mengembangkan logika dalam Metode IQuerable. Di RIA Services dan WebApi, Anda dapat menulis kode apa pun yang Anda inginkan selama Anda kembali IQueryable<T>. Di Layanan Data WCF, Anda HANYA mendapatkan akses untuk menambahkan Pernyataan "Di mana" menggunakan Expression<Func<T,bool>>Metode interseptor. Saya menemukan ini mengecewakan. Aplikasi kami saat ini menggunakan Layanan RIA dan saya merasa kami benar-benar membutuhkan kemampuan untuk mengontrol logika IQuerable. Saya harap saya salah dalam hal ini dan saya hanya melewatkan sesuatu

Selain itu, Layanan Data WCF BELUM mendukung sepenuhnya semua Operator LINQ. Ini masih mendukung lebih dari WebApi sekalipun.

Bagaimana dengan WebApi ???

1. Saya suka kontrol atas Permintaan / Respon Http
2. Mudah untuk diikuti (memanfaatkan pola MVC). Saya yakin lebih banyak perkakas akan datang.

Sampai sekarang (menurut pemahaman saya), tidak ada dukungan "Konteks Data" pada Klien (yaitu Silverlight, Kode Sisi Server ASP.NET, dll), karena WebApi tidak benar-benar tentang Model Data Entitas seperti Layanan Data WCF / OData adalah. Ini dapat mengekspos Koleksi Objek Model menggunakan IQuerable / IEnumerable, tetapi tidak ada "Properti Navigasi" Kunci Utama / Kunci Asing (yaitu faktur pelanggan) untuk digunakan setelah Entitas dimuat pada Klien, karena tidak ada "Konteks Data" yang memuatnya secara asinkron (atau dalam satu panggilan menggunakan $ expand), dan mengelola perubahan. Anda tidak memiliki "representasi" yang dihasilkan kode dari Model Data Entitas Anda pada Klien, seperti yang Anda lakukan di Layanan RIA atau Layanan Data WCF. Saya tidak mengatakan Anda tidak dapat / tidak memiliki Model di Klien yang mewakili Data Anda, tetapi Anda telah mengisi Data secara manual dan mengelola "faktur" mana yang akan ditetapkan dengan setiap "pelanggan" setelah diambil melalui Web. Ini bisa menjadi rumit, khususnya dengan semua hal Async yang terjadi. Anda tidak tahu panggilan mana yang akan kembali lebih dulu. Ini mungkin sulit dijelaskan di sini, tetapi cukup baca tentang hal-hal "Konteks Data" di Layanan RIA atauLayanan Data WCF . Jadi ketika berurusan dengan Aplikasi Lini Bisnis, ini adalah masalah utama bagi saya. Ini terutama didasarkan pada produktivitas dan pemeliharaan. Anda dapat membuat Aplikasi tanpa Konteks Data. Itu hanya membuat segalanya lebih mudah, khususnya di Silverlight, WPF, dan sekarang Windows 8 Metro. Memiliki Entitas relasional yang dimuat ke dalam memori secara asynchronous dan memiliki Two-Binding benar-benar menyenangkan.

Karena itu, apakah ini berarti suatu hari WebApi dapat mendukung "Konteks Data" pada Klien? Saya pikir itu bisa. Selain itu, dengan lebih banyak perkakas, Proyek Visual Studio dapat menghasilkan semua Metode CRUD Anda berdasarkan Skema Database (atau Kerangka Entitas).

Selain itu, saya tahu saya hanya menyebutkan .NET ke .NET Frameworks ketika harus bekerja dengan Layanan Data WCF atau WebApi, tetapi saya sangat sadar bahwa HTML / JS juga merupakan pemain utama. Saya baru saja menyebutkan manfaat yang saya temukan ketika berurusan dengan Silverlight UI, atau ASP.NET Server-Side Code, dll. Saya yakin dengan munculnya "IndexedDB" di HTML5 / JavaScript yang memiliki "Konteks Data" dan Kerangka kerja LINQ di JavaScript juga bisa tersedia, membuat kemampuan kueri Layanan OData lebih mudah dari JavaScript (Anda dapat menggunakan DataJS hari ini dengan OData). Plus, menggunakan KnockoutJS untuk mendukung MVVM dan Binding di HTML / JS juga, akan membuatnya mudah :)

Saya sedang meneliti platform mana yang akan digunakan. Saya akan senang menggunakan keduanya, tetapi saya cenderung condong ke OData berdasarkan fakta bahwa Aplikasi saya berikutnya terutama tentang Analytics (hanya baca) dan saya ingin RESTful Api ekspresif yang kaya. Saya percaya OData + WCF Data Services memberi saya itu karena WebApi hanya mendukung $ take, $ skip, $ filter, $ orderby over Collections. Itu TIDAK mendukung Proyeksi, Termasuk ($ expand), dll. Saya tidak memiliki banyak "Updates / Deletes / Inserts" dan Data kami cukup relasional.

Saya berharap orang lain akan bergabung dalam diskusi dan memberikan pemikiran mereka. Saya masih memutuskan dan ingin mendengar pendapat lain. Saya pikir keduanya adalah kerangka kerja yang bagus. Saya bertanya-tanya apakah Anda harus memilih, mengapa tidak menggunakan keduanya jika diperlukan. Dari Klien, ini semua tentang membangun panggilan REST. Hanya pemikiran saja :)

Kami percaya bahwa API Web menyediakan platform yang tepat untuk layanan OData di masa mendatang dan dengan demikian akan berinvestasi terutama di platform tersebut untuk tumpukan server OData. Kami tentu saja akan terus menempatkan sumber daya yang signifikan ke dalam perpustakaan inti dan klien OData, tetapi kami berencana untuk mengurangi investasi dalam Layanan Data WCF sebagai tumpukan untuk membuat layanan OData.

Blog Tim OData

Jadi, sepertinya sekarang semuanya sudah cukup jelas

Baik Web API dan Layanan Data WCF mendukung OData di luar kotak. Dengan Layanan Data WCF (WCFDS), otomatis. Dengan API Web, kembali IQueryabledari pengontrol Anda dan beri tag metode dengan [Queryable]. Ini akan memberi Anda $filterfungsionalitas yang tadi Anda bicarakan. Dan jika Anda melakukannya dengan cara ini, keduanya dapat menangani JSON dalam respons secara otomatis dengan memasukkan accept=application/jsonheader permintaan. OData dari WCFDS mendukung beberapa kata kunci OData lebih banyak daripada API Web (meskipun hanya $expandkata kunci yang terlintas dalam pikiran), tetapi saya yakin waktu akan memperbaiki ini.

Baik klien .NET dan halaman HTML dapat memanggil kedua alternatif ini dengan mudah, tetapi jika Anda menyukai LINQ, dan Anda sedang membangun klien .NET, WCFDS dapat ditambahkan ke dalam proyek Anda sebagai referensi layanan. Ini memungkinkan Anda untuk melewati semua bisnis HTTP sama sekali dan langsung menanyakan koleksi.

Intinya adalah tidak ada yang mencegah Anda untuk meletakkan file .svc ke dalam proyek ASP.Net MVC Anda. Ini bukan proposisi baik atau. Menambahkan layanan data ke server Anda akan menghemat kebutuhan untuk menulis banyak pengontrol, tetapi tidak mencegah Anda untuk menulis pengontrol tambahan jika Anda mau.

Dengan kata lain :

Jika Anda ingin mengekspos model data (EDM atau lainnya) dengan cepat dan tidak memerlukan banyak kode atau logika bisnis, Layanan Data WCF membuatnya SANGAT mudah dan akan menjadi titik awal yang baik.

Jika, Anda sedang membangun API dan hanya ingin mengekspos beberapa sumber daya (dan logika) menggunakan sintaks atau pemformatan kueri OData, maka ASP.NET Web API mungkin adalah tempat terbaik untuk memulai.

http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx

Devaron memberikan review paling informatif tentang WCF vs Web Api yang belum saya temukan. Terima kasih. Sekarang ke titik WCF menjadi terlalu kompleks, saya akan mengatakan bahwa kompleksitas tidak otomatis negatif. Anda akan bersyukur atas ruang bernapas yang diberikannya di masa depan. Tantangan seperti biasa dengan alat Microsoft adalah kita tidak tahu atau mengontrol masa depan itu. Mari kita berharap bahwa Microsoft berakhir dengan sistem yang lebih terpadu, dan tetap ada selama beberapa tahun.

Saya juga memiliki sistem besar untuk dibangun, dan itu membuat saya stres karena jalannya tidak lebih jelas. Saya berencana untuk menunda selama beberapa bulan lagi sementara ini semua beres. Dan secara pribadi saya rooting untuk datajs (juga lihat JayData)

Sederhananya, mundur dari protokol yang mendasarinya dan lihat ini dari perspektif pengembang / pengguna. API Web adalah Kerangka Istirahat berbasis HTTP kelas pertama Microsoft, bukan WCF. Itu berarti setiap fitur Istirahat yang hilang, spesifikasi, mereka akan ditambahkan ke pipa API Web dan tidak harus ke WCF.

Ya, Anda dapat menerapkannya sendiri di WCF, tetapi seperti yang tertulis dalam kalimat, Anda harus menerapkannya sendiri.

Seperti contoh hari ini yang menerapkan otentikasi 2 faktor untuk API Web membutuhkan waktu kurang dari 15 menit menggunakan OWIN yang merupakan paket nuget Otentikasi / Otorisasi yang dimulai sebagai proyek sumber terbuka.

Saat Anda menggunakan tumpukan teknologi, ada perbedaan besar dalam menggunakan tumpukan kelas satu untuk Microsoft. Anda bahkan akan memiliki kode sampel dan proyek yang diterbitkan MS yang tak terhitung jumlahnya di Github yang dapat Anda salin dan mulai dalam proyek Anda sendiri. Itu membuat perbedaan pada setiap level, dokumentasi, sampel kode, set fitur, dukungan, api pembantu, apa pun namanya.

Jadi saran sederhana saya untuk Anda, jika Anda ingin membangun aplikasi berbasis HTTP Restfull gunakan web API (atau ASP.NET Core untuk portabilitas) dan benar-benar menjauh dari WCF. Jika protokolnya bukan HTTP dan benar-benar tidak bisa HTTP, gunakan WCF.

Ini adalah TL; DR jawaban untuk pertanyaan ini.

WCF adalah pisau swiss untuk obeng API WEB untuk komunikasi dan transfer data: WCF dapat melakukan semua yang dapat dilakukan WEB API, tetapi, jika Anda membutuhkan lebih banyak (misalnya, menggunakan protokol TCP), WCF adalah cara yang tepat.

Berikut ini perbandingan yang bagus .

API WEB

Alasan nomor satu untuk menggunakan WEB API adalah karena ringan. Ini berarti lebih sederhana untuk diterapkan, lebih mudah dipelajari, lebih mudah dipelihara, dll. Ini dirancang khusus untuk Web, yang membutuhkan layanan web RESTful melalui HTTP. Ia melakukan ini dan melakukannya dengan baik. Jika, hanya ini yang Anda butuhkan, WEB API mungkin adalah cara yang tepat.

Juga, ini adalah Sumber Terbuka (jika Anda peduli)

WCF

WCF hanya melakukan lebih dari sekedar WEB API: mendukung beberapa protokol transfer, beberapa pola pertukaran (WEB API memerlukan integrasi dengan SignalR atau Web Sockets), layanan SOAP dapat dijelaskan dalam WSDL, memiliki fitur keamanan tambahan, dan banyak lagi. Gunakan WCF jika Anda memerlukan fungsionalitas tambahan ini.

OData

OData sederhana

Protokol terbuka untuk memungkinkan pembuatan dan konsumsi RESTful API yang dapat dikueri dan dioperasikan dengan cara yang sederhana dan standar. sumber: http://www.odata.org/

Dengan kata lain, level tinggi, ini hanya menstandarkan tata bahasa tertentu untuk permintaan HTTP RESTful. Yang akan memberikan keuntungan yang sama seperti protokol apapun. Dan setidaknya pada 2013, WCF dan WEB API mengizinkan penggunaan OData. Jadi, mungkin tidak perlu mengkhawatirkan OData.