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 ???
- Saya suka kontrol atas Permintaan / Respon Http
- 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 :)