Şu anda WebApi ve WCF Veri Hizmetleri arasında kimsenin bahsetmediği başka önemli farklılıklar var. Keşke MS ikisini karşılaştıran iyi bir makale çıkarsa.
Bir süredir OData'yı ve ayrıca WebApi'yi takip ediyorum. Her zaman birkaç büyük fark buldum.
İlk olarak, patronunuzun OData'yı desteklemedikleri anlamına gelmek üzere "MS WebApi'yi destekliyor" derken ne demek istediğinden emin değilim? IMO, her ikisini de destekliyorlar ve şu anda minimum düzeyde örtüşme var. Windows Azure Data Market Verilerini OData kullanarak gösterir, Azure Tablo Depolama OData kullanır, SharePoint 2010 Verileri üzerinden OData Sorgularına izin verir ve Excel PowerPivot gibi MS ürünleri de bunu destekler. İlişkisel Veriler söz konusu olduğunda çok güçlü bir Sorgu çerçevesi. Ve RESTful olduğu için herhangi bir dil, çerçeve, cihaz vb. Onunla entegre olabilir.
OData + WCF Veri Hizmetleri hakkında sevdiğim şeyler:
OData + WCF Veri Hizmetleri nihayet İstemci Uygulamalarının Web üzerinden Verileri sorgularken daha "anlamlı" olmasına izin verdi. Daha önce, bir kullanıcı arayüzü biraz farklı bir şey istediğinde, alçakgönüllü hale gelen ve sürekli değişiklikler gerektiren katı Web API'leri oluşturmak için her zaman ASMX veya WCF kullanmak zorunda kalıyorduk. İstemci Uygulaması, yalnızca hangi kriterlerin döndürüleceğini belirleyen parametreleri belirleyebilir. Ya da yaptığım gibi yapın ve LINQ İfadelerini "Seri Hale Getirin" ve bunları Parametreler olarak aktarın ve Expressions<Func<T,bool>>Sunucuda yeniden nemlendirin . Terbiyeli. İşi tamamladım, ancak LINQ'yi İstemcide kullanmak ve bunu REST kullanarak Web üzerinden çevirmek istiyorum, bu tam olarak OData'nın izin verdiği şeydir ve kendi "hack" çözümümü kullanmak istemiyorum.
Bu, bir DB Bağlantı Dizesine ihtiyaç duymadan "TRANSACT SQL" i açığa çıkarmak gibidir. Basitçe bir URL ve whoala sağlayın! Sorgulamaya başlayın. Elbette, hem WebApi hem de WCF Veri Hizmetleri, Kimlik Doğrulama / Yetkilendirmeyi destekler, böylece erişimi kontrol edebilir, rollere veya diğer veri yapılandırmasına dayalı ek "Nerede" ifadeleri ekleyebilirsiniz. Bunu SQL yerine Web Api Katmanımda yapmayı tercih ederim (Görünümler veya Depolanan İşlemler oluşturma gibi). Ve artık Uygulamalar kendileri sorgular oluşturabildiğine göre, Ad-Hoc ve BI Raporlama araçlarının OData'dan yararlanmaya başladığını ve Kullanıcıların kendi sonuçlarını tanımlamasına izin verdiğini göreceksiniz. Minimum kontrole sahip oldukları Statik Raporlara güvenmemek.
Silverlight, Windows 8 Metro veya ASP.NET'te (MVC, WebForms, vb.) Geliştirme yaparken, Visual Studio'da WCF Veri Hizmetine bir "Hizmet Referansı" ekleyebilir ve Verileri sorgulamak için LINQ kullanmaya hemen başlayabilirsiniz VE bir İstemci üzerindeki "Veri Bağlamı", değişiklikleri izlediği ve değişikliklerinizi otomatik olarak Sunucuya "Göndermenize" izin verdiği anlamına gelir. Bu Silverlight için RIA Hizmetlerine çok benzer. RIA Hizmetleri yerine WCF Veri Hizmetlerini kullanırdım, ancak o zamanlar DataAnnotations veya Actions'ı desteklemiyordu, ancak şimdi destekliyor :) WCF Data Services, "Projeksiyon" gerçekleştirme yeteneği olan RIA Hizmetlerine göre başka bir avantaja sahiptir Müşteriden. Bu, bir Varlıktan tüm Özellikleri döndürmek istemediğim durumlarda performans konusunda yardımcı olabilir. Bir "Veri Bağlamına" sahip olmak
Dolayısıyla, özellikle SQL Server ve Entity Framework kullanıyorsanız, ilişkilerle Verileriniz varsa, WCF Veri Hizmetleri harikadır. Çok az Kod ile REST üzerinden Sorgulanabilir Veri + Eylemleri (işlemleri çağırma çağrıları, yani iş akışları, arka plan işlemleri) hızlı bir şekilde ifşa edebileceksiniz. WCF Veri Hizmetleri yeni güncellendi. Yeni sürüm piyasaya sürüldü. Tüm yeni işlevselliğe göz atın.
WCF Veri Hizmetlerinin dezavantajı, HTTP Yığını üzerinde kaybettiğiniz "kontrol" dür. En büyük kusurun IQueryable<T>Koleksiyonları döndüren Yöntemlerde olduğunu buldum . RIA Services AND WebApi'den farklı olarak, IQueryable Metodunda mantığı geliştirmek için tam erişime sahip değilsiniz. RIA Servislerinde ve WebApi'de, geri döndüğünüz sürece istediğiniz kodu yazabilirsiniz IQueryable<T>. WCF Veri Hizmetlerinde, YALNIZCA Expression<Func<T,bool>>durdurucu Yöntemleri kullanarak "Nerede" İfadesi eklemeye erişiminiz olur . Bu hayal kırıklığı yarattı. Mevcut uygulamamız RIA Hizmetlerini kullanıyor ve gerçekten IQueryable mantığını kontrol etme yeteneğine ihtiyacımız olduğunu görüyorum. Umarım bu konuda yanılıyorum ve sadece bir şeyi kaçırıyorum
Ayrıca, WCF Veri Hizmetleri de henüz tüm LINQ Operatörlerini tam olarak DESTEKLEMEZ. Yine de WebApi'den daha fazlasını destekliyor.
Peki ya WebApi ???
- Http İsteği / Yanıtı üzerindeki kontrolü seviyorum
- Takip etmesi kolaydır (MVC modellerinden yararlanarak). Eminim daha fazla alet gelecektir.
Şu an itibariyle (anladığım kadarıyla), İstemcide "Veri Bağlamı" desteği yoktur (ör. Silverlight, ASP.NET Sunucu Tarafı Kodu, vb.), Çünkü WebApi aslında WCF Veri Hizmetleri / OData gibi Varlık Veri Modelleriyle ilgili değildir. dır-dir. IQueryable / IEnumerable kullanarak Model Nesneleri Koleksiyonlarını açığa çıkarabilir, ancak Varlıklar İstemciye yüklendikten sonra kullanılacak Birincil Anahtar / Yabancı Anahtar "Gezinme Özellikleri" (yani müşteri.Faturalar) yoktur, çünkü "Veri Bağlamı" yoktur. bu onları eşzamansız olarak (veya $ expand kullanarak bir çağrıda) yükler ve değişiklikleri yönetir. RIA Hizmetlerinde veya WCF Veri Hizmetlerinde yaptığınız gibi, İstemci üzerindeki Varlık Veri Modelinizin kodla oluşturulmuş "temsiline" sahip değilsiniz. İstemcide Verilerinizi temsil eden Modellere sahip olamayacağınızı / sahip olamayacağınızı söylemiyorum, ancak Verileri manuel olarak doldurdunuz ve Web üzerinden erişildiğinde her "müşteri" için hangi "faturaların" ayarlanacağını yönetiyorsunuz. Bu, özellikle tüm Zaman uyumsuz şeyler devam ederken zor olabilir. Önce hangi çağrıların geri geleceğini bilmiyorsunuz. Bunu burada açıklamak zor olabilir, ancak RIA Hizmetlerinde "Veri Bağlamı" konusunu okuyun veyaWCF Veri Hizmetleri . Dolayısıyla, İş Kolu Uygulamaları ile uğraşırken bu benim için büyük bir sorun. Bu, esas olarak üretkenliğe ve sürdürülebilirliğe dayanır. Bir Veri Bağlamı olmadan alışılmadık bir şekilde Uygulamalar oluşturabilirsiniz. Özellikle Silverlight, WPF ve şimdi Windows 8 Metro'da işleri kolaylaştırıyor. İlişkisel Varlıkların belleğe eşzamansız olarak yüklenmesi ve Two-Binding'e sahip olması gerçekten güzel.
Bunu söyledikten sonra, bu WebApi'nin bir gün İstemci üzerinde bir "Veri Bağlamını" destekleyebileceği anlamına mı geliyor? Sanırım olabilir. Ayrıca, daha fazla araçla, bir Visual Studio Projesi, tüm CRUD Yöntemlerinizi bir Veritabanı Şemasına (veya Varlık Çerçevesine) dayalı olarak oluşturabilir.
Ayrıca, WCF Veri Hizmetleri veya WebApi ile çalışma söz konusu olduğunda yalnızca .NET'ten .NET Framework'e bahsettiğimi biliyorum, ancak HTML / JS'nin de önemli bir oyuncu olduğunun farkındayım. Silverlight Kullanıcı Arabirimi veya ASP.NET Sunucu Tarafı Kodu, vb. İle uğraşırken bulduğum avantajlardan bahsediyordum. HTML5 / JavaScript'te "IndexedDB" nin ortaya çıkmasıyla birlikte "Veri Bağlamı" ve JavaScript'teki LINQ çerçevesi de kullanılabilir hale gelebilir, bu da OData Hizmetlerini JavaScript'ten sorgulama becerisini daha da kolaylaştırabilir (DataJS'i bugün OData ile kullanabilirsiniz). Ayrıca, HTML / JS'de MVVM ve Binding'i desteklemek için KnockoutJS'yi kullanmak, onu bir esinti yapacak :)
Şu anda hangi platformu kullanacağımı araştırıyorum. Her ikisini de kullanmaktan mutlu olurdum, ancak bir sonraki Uygulamamın esas olarak Analytics (salt okunur) olması ve zengin, etkileyici bir RESTful API istediğim gerçeğine dayanarak OData'ya yönelme eğilimindeyim. OData + WCF Veri Hizmetlerinin bana bunu sağladığına inanıyorum çünkü WebApi Koleksiyonlar üzerinden yalnızca $ take, $ skip, $ filter, $ orderby'yi destekliyor. Projeksiyonları, İçerirleri ($ genişletir) vb. DESTEKLEMEZ. Çok fazla "Güncelleme / Silme / Ekleme" yok ve Verilerimiz oldukça ilişkisel.
Umarım başkaları da tartışmaya katılır ve düşüncelerini verir. Hâlâ karar veriyorum ve diğer fikirleri duymak isterim. Her ikisinin de çerçevelerin harika olduğunu düşünüyorum. Acaba seçmek zorunda olup olmadığını, gerekirse neden ikisini birden kullanmayasınız? Müşteriden her şey yine de REST çağrıları oluşturmakla ilgilidir. Sadece bir düşünce :)