Ayrı bir projede MVC çözümünde Web API

Yeni bir MVC4 projesi oluşturuyorum ve araştırmalar, javascript'ten sunucu tarafına iletişimin artık denetleyici eylemlerinden ziyade web API çerçevesi aracılığıyla daha iyi başarıldığına inanmamı sağladı. Benim anlayışım bu konuda doğru mu?

Web API ve MVC denetleyicileri arasında tüm özniteliklerimi vb. Paylaşabileceğimi varsayıyorum, bu yüzden ilk bakışta benim için büyük bir değişiklik görünmüyor.

Uygulamaları kurarken, bileşenleri projelere ayırmayı seviyorum. Planım bir MVC projesi ve bir web API projesine sahip olmaktı. Ama sorunlarla karşılaştım. Örneğin, 2 uygulama, ayrı yönlendirme kurulumu vb. İle sonuçlandım.

Öyleyse sorum şu, bir MVC uygulamasında web API çerçevesi aynı proje içinde mi yer almalı, yoksa web API'si kendi başına bir projeye mi ayrılıp sorunların etrafında mı çalışmalı?

Ne yazık ki bu konuda yanılıyorsunuz - web api ve mvc denetleyicileri arasında tüm özniteliklerimi vb. Paylaşabileceğimi varsayıyorum, bu yüzden benim için büyük bir değişiklik görünmüyor.

Web API ve MVC tarafından kullanılan kavramların çoğu, ilk bakışta benzer olsalar da aslında uyumlu değildir. Örneğin, Web API öznitelikleri System.Web.Http.Filters.Filterve MVC öznitelikleri System.Web.Mvc.Filter- ve birbirinin yerine kullanılamaz.

Aynısı diğer birçok kavram için de geçerlidir - model bağlama (tamamen farklı mekanizmalar), rotalar (Web API, her ikisi de aynı temel RouteTable üzerinde çalışsalar bile, Routes değil HTTPRoutes kullanır), bağımlılık çözümleyici (uyumlu değil) ve daha fazlası - yüzey, pratikte çok farklıdır. Dahası, Web API bir alan kavramına sahip değildir.

Nihayetinde, başarmaya çalıştığınız tek şey JSON içeriğini sunmanın "yeni, modaya uygun" bir yoluna sahip olmaksa - bu yola girmeden önce iki kez düşünün. Gerçekten HTTP'yi benimsemeyi ve uygulamanızı RESTful bir şekilde oluşturmayı düşünmüyorsanız, mevcut herhangi bir kodu yeniden düzenlemenizi kesinlikle önermem.

Her şey gerçekten ne inşa ettiğinize bağlı. Yeni bir projeye başlıyorsanız ve ihtiyacınız olan tek şey, web uygulamanızı kolaylaştırmak için biraz JSON sunmaktır - bazı potansiyel olarak yinelenen kodlarla (yukarıda bahsettiğim şeyler gibi) yaşamaya istekli olmanız koşuluyla, Web API kolayca içinde barındırılabilir. ASP.NET MVC ile aynı proje.

Çevrimiçi hizmetiniz için uygun bir API oluşturacaksanız - belki de harici müşteriler tarafından veya mobil uygulamalarınızı beslemek gibi çeşitli cihazlar tarafından tüketilecekse - Web API'yi ayrı bir projeye ayırırım.

IMO, güvenlik ve dağıtım kararınızı yönlendirmelidir. Örneğin, MVC uygulamanız Form kimlik doğrulamasını kullanıyorsa ancak API'niz için Temel kimlik doğrulaması (SSL ile) kullanmakla ilgileniyorsanız, ayrı projeler hayatınızı kolaylaştıracaktır. Sitenizi www.example.com'da barındırmak, ancak API'nizi api.example.com olarak barındırmak (www.example.com/api'ye kıyasla) istiyorsanız, ayrı projeler hayatınızı kolaylaştıracaktır. Projelerinizi buna göre ayırır ve alt alan adı alırsanız ve MVC uygulamanızdan kendi API'nizi kullanmayı amaçlıyorsanız, API'nize yapılan istemci tarafı çağrıları için Aynı Kaynak İlkesi sorunuyla nasıl başa çıkacağınızı bulmanız gerekecektir . Buna Ortak çözümler kaldıraç için vardır JSONP veya CORS (tercihen mümkünse).

Güncelleme (26.3.2013): Resmi CORS desteği geliyor: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Bir dereceye kadar deneyimden sonra (uygulamalar ve mvc için API oluşturma). Çoğunlukla ikisini de yapıyorum.

Diğer istemcilerden veya diğer cihazlardan (Android / IOS uygulamaları) gelen api çağrıları için ayrı bir proje oluşturuyorum. Bunun nedenlerinden biri, kimlik doğrulamanın farklı olması, belirteç tabanlı olmasıdır (onu durumsuz tutmak için). Bunu MVC uygulamamda karıştırmak istemiyorum.

Mvc uygulamama yapılan javascript / jquery api çağrılarım için işleri basit tutmayı seviyorum, bu nedenle MVC uygulamama bir web api ekliyorum. Javascript api çağrılarımla token tabanlı kimlik doğrulamaya sahip olmayı düşünmüyorum, çünkü hey, aynı uygulamada. Sadece kullanabilirsiniz [authorize]bir kullanıcı oturum değilken, o veriyi almazsınız, bir API bitiş üzerinde niteliği.

Ayrıca, alışveriş sepetleriyle uğraşırken ve bir oturumda (oturum açmamışken) bir kullanıcının alışveriş sepetini saklamak istiyorsanız, javascript kodunuz aracılığıyla ürün eklerseniz / silerseniz, bunu API'nizde de bulundurmanız gerekir. Bu, API'nizi kesin olarak durum bilgili hale getirecek, ancak aynı zamanda MVC-API'nizdeki karmaşıklığı da azaltacaktır.

SimpleInjector'dan (IoC framework) Steven, iki ayrı proje öneriyor: DependencyResolver.SetResolver ile HttpConfiguration.DependencyResolver arasındaki fark nedir? WebAPI'de

Geçenlerde neredeyse aynı şeyi yaptım: VS2012'de Web API şablonunu seçerek yeni bir MVC 4 web uygulaması projesiyle başladım.

Bu, MVC ile aynı uygulamada barındırılan bir Web API oluşturacaktır.

ApiControllers'ı ayrı bir sınıf kitaplığı projesine taşımak istedim. Bu oldukça kolaydı ama çözüm biraz gizliydi.

MVC 4 projesinin AssemblyInfo.cs içinde benzer kod satırı ekleyin

[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]

Artık LibraryRegistrator sınıfına ihtiyacınız var (ne olursa olsun adlandırmaktan çekinmeyin)

public class LibraryRegistrator
    {
        public static void Register()
        {
            BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
        }
    }

MVC 4 projesinde ayrıca Api kitaplığına başvuru ekleyin.

Artık Api denetleyicilerini kendi ayrı sınıf kitaplığınıza (yourown.dll) ekleyebilirsiniz.

Projeniz iki "ön ucu" garanti edecek kadar karmaşık olsa bile, yine de son çare olarak webapi'yi ayrı bir projeye bölmeyi düşünürdüm. Dağıtım sorunları yaşayacaksınız ve bir aceminin çözümünüzün yapısını anlaması zor olacaktır. Yönlendirme sorunlarından bahsetmiyorum bile.

System.web ad alanını tek bir "sunum katmanında" izole tutmayı amaçlıyorum. WebAPI olmama rağmen presentational hala uygulamanın arayüzünün bir parçasıdır. Mantığı denetleyicilerinizde değil, etki alanınızda tuttuğunuz sürece çok fazla sorunla karşılaşmamalısınız. Ayrıca Alanlardan yararlanmayı da unutmayın.

Web.Api için ayrı DLL kurulumuna ek olarak.

Sadece bir öneri:

1. Projeyi Oluşturun
2. Nugget WebActivatorEx

3. App_start ile çağrılacak bir sınıf yöntemi oluşturun

   [derleme: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Başlat")]

   [derleme: WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "Kapatma")]

4. Başlangıç ​​Yöntemi içinde bir web.api rotası kaydedin

   public static void Start () {GlobalConfiguration.Configure (WebApiConfig.Register); }

5. Projeyi Web Projesine referans verin. Başlangıç ​​Yöntemini etkinleştirmek için.

Bu yardımcı olur umarım.

API denetleyicilerini yeni bir projeye ayırmaya çalıştım. Tek yaptığım yeni bir kitaplık projesi oluşturmak, denetleyicileri API adlı klasöre taşımak. Daha sonra kütüphane projesinin referansını MVC projesine ekledik.

WebAPI yapılandırması MVC projesinin kendisinde bırakılmıştır. İyi çalışıyor.