WCF ve Web API üzerinden teknik tartışmayı nasıl yönetirim?

Şu anda 15 geliştiriciden oluşan bir ekibi yönetiyorum ve WCF'e karşı Web API kullanımı üzerine tartışarak, ekibin tamamen zıt iki takıma ayrıldığı teknolojiyi seçerken bir noktada kaldık.

Web API kullanımını destekleyen A Takımı şu nedenleri ortaya koymaktadır:

1. Web API sadece modern servis yazma yöntemidir ( Wikipedia )
2. WCF, HTTP için bir ek yüküdür. TCP, Net Borular ve diğer protokoller için bir çözümdür
3. WCF modelleri [DataContract] & [DataMember] ve bu niteliklerden dolayı POCO değil
4. SOAP, JSON kadar okunaklı ve kullanışlı değildir
5. SOAP, JSON'a kıyasla ağ için bir ek yük (HTTP üzerinden aktarma)
6. Aşırı yükleme yöntemi yok

WCF kullanımını destekleyen B takımı şöyle diyor:

1. WCF çoklu protokolleri destekler (konfigürasyon yoluyla)
2. WCF dağıtılmış işlemleri destekliyor
3. WCF için birçok iyi örnek ve başarı öyküsü var (Web API hala gençken)
4. Çift yönlü iletişim için çift yönlü mükemmel

Bu tartışma devam ediyor ve şimdi ne yapacağımı bilmiyorum. Şahsen, sadece doğru kullanım yeri için bir araç kullanmamız gerektiğini düşünüyorum . Başka bir deyişle, HTTP üzerinden bir hizmet göstermek istiyorsak Web API kullansak daha iyi olur, ancak TCP ve Dubleks olduğunda WCF kullanırız.

İnterneti arayarak sağlam bir sonuç alamıyoruz. WCF'yi desteklemek için pek çok yayın var, ancak tam tersine insanları bundan şikayet ediyorlar. Bu sorunun doğasının tartışılabilir görünebileceğini biliyorum, ancak karar vermek için iyi ipuçlarına ihtiyacımız var. Bir teknolojiyi tesadüfen seçmenin bizi daha sonra pişman edebileceği bir noktada kaldık . Açık gözlerle seçmek istiyoruz.

Kullanımımız çoğunlukla web için olurdu ve hizmetlerimizi HTTP üzerinden göstereceğiz. Bazı durumlarda (yüzde 5 ila 10 arası) dağıtılmış işlemlere ihtiyacımız olabilir.

Ben şimdi ne yapmalıyım? Bu tartışmayı yapıcı bir şekilde nasıl yönetirim?

Her iki taraf da iyi bir argümana sahipse ve konuyla ilgili görüşler bir fikir birliğine varmayacak kadar güçlü olduğunda, bir yönetici olarak bir karar vermeniz ve tartışmayı sonlandırmanız gerekir. Aksi takdirde, sadece daireler çizecek ve tüm katılımcıların pozisyonlarını daha da güçlendirecektir. Ne kadar uzun süre beklerseniz, "kaybetme" tarafının yenilgiyi kabul etmesi ve sonuçla verimli bir şekilde çalışması daha da zorlaşacaktır.

Tüm argümanları not edin, proje için önemine değer verin ve kararınızı verin. Yapamadığın zaman, yazı tura at. Projeniz muhtemelen her iki teknoloji ile başarılı bir şekilde tamamlanabilir ve gereksiz tartışmalarla değerli zamanınızı harcamak, sadece gereksiz paraya mal olacaktır.

Her iki tarafın da bütün tartışmalarında% 100 doğru olduğunu varsayarsak, hangisi önemli?

WCF modelleri [DataContract] & [DataMember] ve bu niteliklerden dolayı POCO değil

Umurunda mı? POCO gerektiren bir şey yapmayı mı planlıyorsunuz?

WCF dağıtılmış işlemleri destekliyor

Yine bu, kullanmayacağınız ve diğer yolu kullandığınız için sahip değilseniz, inşa etmeniz gereken bir şey mi?

Temel olarak hangisinin kalbine gidelim:

• İhtiyacınız olan her şeyi sunar (Hiçbiri, ihtiyaç duyduğunuz her şeyi teklif etmiyorsa, bu sizi en az miktarda iş yapmak zorunda bırakır).
• Kullanmayacağınız, ancak yine de katlanmak zorunda olduğunuz en az miktarda çöpü sunar.

Yapmanız gereken şeyin yolunda olmayan herhangi bir tartışma ilgisizdir ve kararınızı etkilememelidir, gelecekteki genişlemeyi düşünmek için bir kıkırdama odası ile.

İki sentimi de içine koy.

Bir yönetici olarak, takım arkadaşlarınızdan Yagni ilkesini akıllarında tutmalarını istemeniz gerekir . Bu, her iki Takımın öne sürdüğü sebeplerin listesini azaltmaya yardımcı olacaktır.

Kullanımımız çoğunlukla web için olurdu ve hizmetlerimizi HTTP üzerinden göstereceğiz. Bazı durumlarda (yüzde 5 ila 10 arası) dağıtılmış işlemlere ihtiyacımız olabilir.

Dağıtılmış işleme dalmak yerine, bunun yerine tazminatla çalışmayı düşünmelisiniz .

Dikkate alınması gereken son şey öğrenme eğrisidir. Projenizin son tarihine bağlı olarak, bir yönetici olarak, yeni bir teknoloji öğrenmeye başlamanın uygun olup olmadığına karar verebilmelisiniz.

Eğer harcayacak çok zamanınız varsa, o zaman A ve B Takımı'nın aynı şartlara dayanan kavramların kanıtını üretmek için bir gününün olacağı bir Yenilik Gününe gidin .

Bu arada, " WCF modelleri POCO değil, [DataContract] ve [DataMember] ve bu nitelikler nedeniyle " diyen adama, ona POCO'ların genel olarak etki alanı varlıkları olduğunu ve en iyi uygulamanın olmadığını söylediğini söyle. etki alanınız herhangi bir müşteriye itiraz ediyor, DTO'lar bunun için var.

Ben şimdi ne yapmalıyım? Bu tartışmayı yapıcı bir şekilde nasıl yönetirim?

İlk olarak, öznelliği uzak tutun. Senin WebAPI takımın argümanlar, ben bulmak "Web API sadece modern bir yoldur" *, "Çünkü bu niteliklerin, WCF modelleri POCO değiliz" ve "SABUN olarak okunabilir ve JSON olarak kullanışlı değildir" , düz yanlış değilse oldukça inatçı ve karar vermenize yardımcı olmayacak.

Öyleyse ne yapmalı: hizmet (ler) inizle ne yapmak istediğinize karar verin , daha sonra bu hedefe uygunluk ve en az acı ile sürdürülebilirliği ve genişletilebilirliğini içeren bir teknik seçin. Bunu, herhangi bir özelliğin kullanılacak çerçeve tarafından desteklenip desteklenmediğini araştırarak yapabilirsiniz.

İlginç okuma materyali:

• Mvc 4 ve Wcf Web Uygulamaları
• WCF veya ASP.NET Web API'leri? Konuyla ilgili iki kuruş
• WebAPI veya WCF?

*: bunun için Wikipedia'ya atıfta bulunduğunuza dikkat edin: " Web 2.0 web uygulamaları, SOAP tabanlı web hizmetleriyle hizmet odaklı bir mimariden (SOA), RESTful web kaynaklarının daha uyumlu koleksiyonlarına doğru ilerlemiştir" . Bu, hizmetinizin bir web sayfasından ne zaman tüketileceğine ilişkin bir örnek. Bu, WebHttpBinding kullanarak WCF ile de kolayca yapılabilir. "Bunun için WebAPI kullan" yazmıyor .

Bu soru "tartışmanın nasıl yönetileceği" nin ötesine uzanıyorsa : hizmetler web dışı müşteriler tarafından tüketilecekse, WCF'yi kullanırdım çünkü meta verileri şaşırtıcı derecede kolay yazılmış bir müşteri oluşturma olanağı sağlar.

Takım yönetimi bir yana, diğerini seçemezsiniz. Her web servisinin amacına bakmanız ve uygulamanın belirli bir bölümü için uygun teknolojiyi kullanmanız gerekir. Ekip varlık çerçevesi kullanırken mağaza prosedürlerini yasaklamak gibi bir şey.

Kullanımımız çoğunlukla web için olurdu ve hizmetlerimizi HTTP üzerinden göstereceğiz. Bazı durumlarda (yüzde 5 ila 10 arası) dağıtılmış işlemlere ihtiyacımız olabilir.

Ardından WCF'ye bu% 5 ila% 10 web servislerini yazıyorsunuz. Hizmet başka projelerde dahili olarak referans gösteriliyorsa, tartışma olmaz. Müşteri proxy'si oluşturmak için WCF sözleşmesini içe aktarma kabiliyetinin avantajı tartışmaya açık DEĞİLDİR. Bütünleşme, verimlilik ve tür güvenliğini tamamen yeni bir seviyeye taşıyor.

Asp.net web api'de genel api (belki) / Ajax talepleri için ne kullanılacağını yazıyorsunuz.

Yalnızca sayfaya özel ajax aramasıysa, Asp.Net MVC'yi kullanabilirsiniz.

Seçme, hepsini kucakla. WCF ve Asp.net web api farklı amaçlara hizmet eder. Kimse meyve salatalarında hem elma hem de portakal olamayacağını söyleyemez. Birini diğerinden seçmeye çalışmak ve her senaryoyu aşağıya çekmek sadece tembellikten ibarettir.

Ekibimiz birkaç ay önce benzer bir tartışma yaptı. Bizim için belirleyici olan faktör, her bir teknolojiyi nasıl yaratacağımız ve uygulayacağımıza bağlıydı. Zaten bir MVC uygulaması oluşturduğumuz ve veri bağlama için Knockout.js kullandığımızdan, MVVM'yi kontrol üniteleriyle yalnızca veriler için bir API olarak kullanıyorduk.

Bu, teknolojilerin kullanımımızı bu proje ile şu şekilde kategorize etmemizi sağladı:

• Web API, nakavt ve Ajax çağrıları için API olarak kullanılacak ve onları MVVM modeli için komutlarımız haline getirecek. Web uygulaması için iş mantığımız, bu sınıfın arkasına çeşitli sınıflar, depolar ve fabrikalar tarafından sarılmaktadır.
• WCF daha sonra veri depomuzda kullanılır, veritabanımızdaki verileri yalnızca bu web sitesi için değil, açığa çıkarılan verileri tüketen herhangi bir site veya hizmet için de kullanır.

Bu popüler veya aşırı bir teknik cevap olmasa da, ilk önce neye ihtiyacınız olduğunu ve teknolojinin nasıl yardım edeceğini veya teknolojinin yardımcı olup olmayacağını belirlemek ekibimin hangi teknolojiyi nerede kullanacağına karar vermesine yardımcı olan şeydir.

Başka bir deyişle, HTTP üzerinden bir hizmet göstermek istiyorsak Web API kullansak daha iyi olur, ancak TCP ve Dubleks olduğunda WCF kullanırız.

Bu en makul yaklaşım olacaktır. Her ikisinin de farklı amaçlara hizmet ettiği aynı web uygulamasında hem WCF hem de WebApi hizmetlerinin bulunması oldukça yaygındır.

Sadece birkaç argümanı düzeltmek için:

WCF modelleri [DataContract] & [DataMember] ve bu niteliklerden dolayı POCO değil

Birçok durumda WCF modelleri datacontract / datamember nitelikleri olmadan çalışır .

SOAP, JSON kadar okunaklı ve kullanışlı değildir

Bu doğru değil, ancak WCF web servisleri genellikle şişirilmiş SOAP yerine düz XML taşırlar. Bu kesinlikle bir okunabilir.

WCF için bir argüman : eğer bir WSDL mevcutsa, hemen hemen tüm teknolojilerde meta verilerden proxy'ler oluşturabilecek tonlarca araç vardır. Öte yandan, JSON Şeması henüz geniş bir şekilde desteklenmemektedir.

Neden WCF Veri Servisleri'ne girmiyorsunuz? güzel OData / webapi stil sorguları ve WCF'nin güçleriyle kullanılabilirliği ve JSONpara cezası geri dönme yeteneği . Ayrıca aşağıdaki gibi bir güzel otomatik wcf barındırma kodu varsa Wcf o kadar da kötü değil:

https://github.com/ImaginaryDevelopment/MvcOdata

Çok uzak olmadıklarını söyleyebilirim, ancak WebApiön uçta ve WCF data servicesorta katmanda kullanmaya başladığımızda , WebApidize içeren ya da dize eşleşen odata işleçleri gibi basit şeylerin üstüne attılar.

İyi bir mimar, karar vermeleri için kesinlikle gerekli olana kadar teknoloji kararlarını geciktirir.

Başka bir deyişle, müşterinin gerçekten bağlanması gerekene kadar kararı vermeyin. Tamamen test edilmiş bir servis katmanı üzerinde bir taşıma / haberleşme mekanizması kullanmadan oluşturabilirsiniz. Çalışmanın% 95'i + adaptörün çerçevenin dışında "altında" yapılabilir.

Bu hizmetleri uzaktaki müşterilere sunma zamanı geldiğinde, en güncel çerçeveyi raftan seçebilir ve çok yönlü bir servis katmanı üzerine ince ambalajlar yazabilirsiniz.

Cehennem, "gerçek" servis katmanınız iyi yapılırsa, minimum maliyetle birkaç ambalajı deneyebilirsiniz.

Zaten dogmatik cevap bu. Uygulamada , sen seç isteyebilirsiniz basit hala üzerinde bağımlılık sınırlamak ve bir olarak kesinlikle davranın ama - erken ve sık entegrasyon testleri kolaylaştırmak için raftan aracı basitçe üzerinde ince haberleşme tabakasının gerçek hizmetler.

Bu yaklaşım, muhtemelen başlangıçta kullanmanın en basit aracı almak olduğunu göreceksiniz ve hiç kimse yaygara olacak ekip, daha sonra bir daha sofistike veya şık aracını veya çerçeve uygulayabilirsiniz bildiği için, gerekirse az çabayla.

Bu yüzden şimdi aynı seçimle karşı karşıyayım , şu anda ekibimizin WCF'den kullandığı özelliklerin alt kümesinin ne olduğunu sordum . Farklı protokoller kullanıyor muyuz? Hayır. İşlem desteği kullanıyor muyuz? Hayır (özel nihai tutarlılık mekanizmaları kullanıyor olsak da). Dubleks kullanıyor muyuz? Hayır.

Neden Web API kullanmak istiyoruz? Daha kolay ön uç entegrasyonu (mevcut ek servis katmanını kaldırır), müşterilere yanıt vermek için SignalR, GET'leri önbelleğe almak.

Belki başka nedenleri de bulabiliriz :) Ayrıca WCF ile kalmak için sebepler.

Senin pozisyonunda olsaydım, takım yeteneklerini inceleyerek başlardım. Ekibinizdeki herkes WCF'yi zaten biliyorsa ve yalnızca küçük bir yüzdesi Web API'sını biliyorsa, kararınız sizin için zaten verilir.

Elbette, vaktiniz varsa, bilgi tabanınızı öğrenme ve geliştirmeye yatırın, ancak iş gereksinimi ve şirket verimliliği pahasına değil.

Hangi etkileşim modelini desteklemeniz gerektiğini sordum? İstediğiniz harici arayüz RPC veya REST'e daha çok benziyor mu? Tecrübelerime göre, genellikle bir veya diğeri arasında bir yerdedir.

Net'teki diğer projeler için kendi servislerinizi mi tüketiyorsunuz? Bu muhtemelen sorabileceğiniz en açık soru. WCF, arayüzlerinizi ayrı bir sınıf kütüphanesinde soyutlayabilme ve müşterinizi kurup enjekte edebilme avantajına sahiptir. Bunun bir uzantısı olarak, WCF tabanlı projenizi hem JSON hem de SOAP / WSDL uç noktalarına monte edebilirsiniz. WCF ayrıca tanımlanmış arayüzlerinize karşı daha iyi güvence sunar.

Bununla birlikte, genel olarak diğer platformlardan XML istemcilerinin olmasını beklerseniz, SOAP’ın basit JSON uç noktalarının ötesinde ölçülebilir bir ek yükü olsa bile JSON / Web API yolunu izlerseniz, o zaman uç noktalarınız ve API'nizle nasıl etkileşim kuracağınızı belgelemek konusunda çok daha iyi olmanız gerekir.

Genel olarak, verileri nasıl göndereceğinizi ve tek bir istek nesnesi yapısı için nasıl bir cevap istediğinizi belirten basit bir API belgesi yazmanızı öneririm. Test durumunuzu en evrensel şekilde yazın ve bu şekilde belgeleyin. Basit bir kıvrılma ifadesi öneririm. Daha sonra üyelerinizden birkaçının WCF ve Web API'sı kullanarak bunu uygulamasını sağlayın. O zaman hangisinin kazandığını görün.

Şahsen, WCF ile göreceli olarak büyük projeler ve uygulamalar yapmış olmama rağmen, aslında aklımda, JSON sonuçlarını kullanan ve Global.asax.cs'ta hata koşullarıyla başa çıkmak için bazı davranışları geçersiz kılan davranışlar gibi basit WCF olan en basit uygulamaya yöneliyorum. Bir API'nin belgeleri curl ifadeleri içeriyorsa ve API'nizin tüm işlevlerini curl örnekleri ile uygulayabiliyorsanız, müşterilerin web arayüzlerini destekleyen herhangi bir dilde uygulanması çok daha kolay hale gelir. Burası gerçekten WCF'nin düşmeye başladığı yer. Agnostik dokümantasyon ile iyi tanımlanmış bir API'ye sahip olmak, yabancı sistemlerle çalışırken otomatik takımlama yapan yapılara sahip olmaktan daha iyidir. Diğer platformlardan bu sistemlerin bir tüketici olarak konuşma.

Bunun ötesinde bir şey, müşterinizi iki ayrı dilde uygulamak. Bir müşteri C # yapın, ancak Node.js veya Python'da da bir tane yapın ve ne kadar uygun olduklarını görün. Bu alıştırma tek başına API'nızdaki gevşek uçları sallamanıza yardımcı olacaktır.