İnsan etkileşimi ile programlı hizmet odaklı kullanım tartışmasının net olduğunu düşünüyorum.
Ama aynı API ile bağlı verileri kullanan bir programlı API ve bir web sitesi kullanan bir uygulama oluşturmak olsaydı, sadece ASP.NET kullanmaya yönelik yalın mı?
Aynı uygulama üzerinde çalışmak için ASP.NET ve WCF'yi entegre etmek ne kadar kolay?
Yanıtlar:
Hem ASP.NET/MVC hem de WCF kullanan tek bir uygulama yazarken, bu harika değil. WebAPI konuları geliştirmiş olabilir, ancak aynı uygulamada WCF ve MVC kullanan bir projede, aynı kavramları temsil etmek için biri WCF kodu ve diğeri MVC için iki farklı model setini sürdürdüler. kodu. İki model arasında bir şeyler çevirmek için yazmak zorunda oldukları tüm haritacıları hayal edebilirsiniz - orada kaçınılabilecek / kaçınılabilecek çok sayıda kod satırı vardı.
Bunun olmasının bir kısmı, MVC bunu gerektirmezken, WCF istek ve yanıt nesnelerine [DataContract] ve özelliklerine [DataMember] ile açıklama eklenmesi gerektiğidir. Deyimsel MVC ise WCF DataContracts'tan farklı hedeflere sahip ViewModels'i isteyecek. Tabii ki, iki tam alan adı nesnesi kullanımının Conway yasasıyla WCF ve MVC çatışmasından daha fazla ilgisi olması mümkündür , ancak WCF ve MVC'nin çıktı ve girdi açısından farklı hedefleri ve gereksinimleri olduğunu belirtmek gerekir.
Şahsen, özellikle birden fazla istemci isteyebileceğiniz zaman basit ama güçlü bir hizmet odaklı arka uç API geliştirmenin bir parçasıyım. Mükemmel JavaScript MVVM ve mikro-MVC çerçevelerinin ortaya çıkması, BackboneJS , KnockoutJS ve diğerlerini kullanarak uygulama kodu yazmanın yetenekli bir geliştirme ortamına izin verdiği için bunu doğal bir seçim haline getirdiğini düşünüyorum . Daha sonra, web uygulamanızı oluşturmak için seçtiğiniz mikro MVC'de veya bir mobil istemcide arka ucu tüketebilirsiniz ve iş ortaklarınız da aynı API'yı uzaktan tüketebilir.
Öneri
WebAPI veya Hizmet Yığını , arka uç API'nizi oluşturmak için iyi aday olabilir. Son birkaç aydır kullandığım ve WCF için mükemmel bir yedek olarak bulduğum için Service Stack'ı öneriyorum. Şu anda benim hizmet yığınında bir öğretici dizi yazıyorum blogda .
Hizmet yığınını koruyan grup , özellikle zorlayıcı olduğuna inandığım bir geliştirme deseni gösteren klon gibi StackOverflow geliştirmek için çerçeveyi kullanarak örnek bir uygulama yayınladı . Bir MVC web sitesi, bir mobil uygulama veya hemen hemen başka bir şey tarafından tüketildiğini hayal edebileceğiniz basit, model tabanlı hizmetler arka ucu içerir. ServiceStack'ın tasarım hedefleri, istemci ve sunucu arasında daha az eşleşmeye yol açacak bir modeli açıkça teşvik eder. Fikir, GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)daha az yöntem lehine çağrılarla konuşkan API'lardan kaçınmaktır . Aynı şeyi servis yığınına şu şekilde de uygulayabilirsiniz:
[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers
{
public int? RegionId { get; set; }
public string SearchTerm { get; set; }
}
public class CustomersService : Service
{
public object Get(Customers request) {
// handle request
return new CustomersResponse();
}
}
Fayda, Gözlerime yerine çok sayıda ve ayrı yöntemlerle sürü üzerinde iş mantığı yayılmasının yarattığı olmasıdır GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), bu bir yerde tüm bu. Bu, daha sürdürülebilir bir koda yol açmalıdır.
Tesadüfen, Stack Exchange orijinal Servis Yığını yazarını işe aldı . Hizmet Yığını projesine aktif olarak devam ediyor .
Özellikle belirli şeyler için mesaj kuyruklarına düşkünüm - ve WCF buna izin verirken, WebAPI buna izin vermez. ServiceStack, aynı web hizmetinin MQ aracılığıyla çağrılmasına izin verir. Bununla ilgili daha fazla bilgi için şu adresteki Redis MQ Ana Bilgisayarına bakın: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@tzerb IMO'ya doğru cevap verdi ama bu cevabı uzatmak istedim. Şu anda beta aşamasında olan bir ASP.NET Web API ve bir OSS projesi aradığınız en yakın çerçevedir.
Ürünün kısa açıklaması aşağıdaki gibidir ( ASP.NET Web API sayfasından alıntılanmıştır ):
ASP.NET Web API, tarayıcılar ve mobil cihazlar da dahil olmak üzere çok çeşitli istemcilere ulaşan HTTP hizmetleri oluşturmayı kolaylaştıran bir çerçevedir. ASP.NET Web API, .NET Framework üzerinde RESTful uygulamaları oluşturmak için ideal bir platformdur.
Web API'nizi tüketmek için kullanıyor olabileceğiniz istemci uygulamasına gelince, kesinlikle bir ASP.NET uygulaması olmak zorunda değildir. JavaScript kullanarak API'nızı statik bir HTML sayfasıyla tüketebilirsiniz. Bunu jQuery gibi bazı kullanışlı JavaScript kitaplıklarıyla kolayca yapabilirsiniz.
Öte yandan, API'nizi herhangi bir ASP.NET uygulamasında sunucu sitesinde kesinlikle tüketebilirsiniz. Web API projesi, HTTP hizmetlerini tüketmeyi kolaylaştıran HttpClient adlı yeni bir HTTP .NET istemci API'sini de tanıttı.
Genel olarak, başlamanız için iyi kaynaklar:
ASP.NET Web API'sine Başlarken - Eğiticiler, Videolar, Örnekler
Projenin hala beta aşamasında olduğunu unutmayın. Projede yayınlanmamış en son güncellemeler hakkında bilgi yayınladığı Henrik F Nielsen blogunu takip etmenizi tavsiye ederim . Projenin kaynak koduna ve ASP.NET Web Stack projesi içindeki geliştirme akışına ulaşabilirsiniz .
Mevcut kılavuz REST için WCF yerine MVC Web API kullanmak olduğunu düşünüyorum. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
Geliştirme modeli oldukça yakındır ve WCF'nin bazen kötü yapılandırmasını atlarsınız.