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


88

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ı?

Yanıtlar:


110

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.


2
+1 Mükemmel cevap. Başlangıçta hem MVC hem de WebAPI'nin özellikle filtreler, model bağlama vb. Durumlarda kodun bir kısmını paylaşabileceğini düşündüm, ancak bunlar tamamen farklı.
VJAI

5
Evet, böyle bir senaryoda sadece Visual Studio'da yeni bir MVC4 projesi başlatın ve bir proje şablonu istendiğinde (ikinci ekran) sadece Web API'yi seçin. Bu, Nuget'ten Web API'yi yükleyecektir ve açıkladığınız durumda tamamen iyi olacaktır. Global.asax'a eklenen ayrı bir Web API yapılandırma dosyası elde edersiniz. Ek olarak, API Denetleyicilerini ayrı bir klasöre ayırmak isteyebilirsiniz (varsayılan olarak bunlar MVC denetleyicileriyle birliktedir). Son olarak, varsayılan rotalar açıkça ayrı ayrı yapılandırılır ve birbiriyle çakışmaz
Filip W

9
Keşke liderimin mevcut projemizi tasarlamadan önce bu yazıyı okumasını isterdim.
Billdr

2
@FilipW İyi açıklamalar için teşekkürler. Ayrıca bir MVC uygulamam var ve Android uygulamaları için servis kullanmak için WebAPI2 kullanacağım. Öte yandan, David Peden'in aşağıda söylediği gibi, WebAPI için yeni bir ayrı proje oluşturmaya karar verirken güvenlik, bakım ve dağıtım da çok önemlidir. Bu durumda, onları akılda tutarak ne önerirsiniz? WebAPI için yeni bir ayrı proje oluşturmak veya mevcut MVC projesini kullanmak için? Şimdiden teşekkürler.
Jack,

1
Çok iyi "Ç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 kullanılmak üzere - Web API'yi yalnızca ayrı bir projeye ayırırım." çiviyi kafaya vurur ve hangi yolla yapılacağını belirlemeyi kolaylaştırır.
ozzy432836

27

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


Web API'yi MVC uygulamamla entegre etme veya onu ayrı bir proje olarak edinme kararıyla ilgili sorunları kafamda bulmaya çalışıyorum. Web barındırıcımdaki bir alt etki alanına bir Web API HelloWorld uygulamasını başarıyla dağıtabildim. Bu ayrı projeden, MVC web uygulamamdaki Modeli kullanacağım ve bu ayrı projedeki kodu çağıracağım. Ayrı bir projenin bu rotasından gitmek daha kolay gibi görünüyor, ancak bu yaklaşımla hangi konularla karşılaşabileceğimi düşünüyorsunuz?
Ciaran Gallagher

2
Şahsen, görünüm modelinizi API'niz için DTO'nuz olarak kullanmam. Görünüm modelleriniz ve API imzalarınız birbirinden uzaklaştıkça, bu kararın yolda ciddi sıkıntılara neden olacağını umuyorum. SoC ( en.wikipedia.org/wiki/Separation_of_concerns ) çok önemlidir.
David Peden

@DavidPeden WebAPI için yeni bir ayrı proje oluşturmanızı öneriyorsunuz. Bu doğru mu? Öte yandan, WebAPI için yeni bir ayrı proje oluşturacağım (şu anda uygulamamda bir UI Layer (MVC) ve Data Layer (Class Library) var.Yani ben de DI kullanıyorum ama kullanıp kullanamayacağımı merak ediyorum Yeni oluşturulan WebAPI projesi için Veri Katmanındaki aynı Varlıklar, Depolar, Arayüzler ve Soyut sınıflar ve yapmam gereken tek şey WebAPI Denetleyicileri oluşturmak mı yoksa hepsini de (Varlıklar, Depolar, Arayüzler ve Özet sınıflar) tekrar WebAPI için? Herhangi bir yardım lütfen?
Jack

1
@ H.Johnson Anlamlı genel tavsiyeler vermek zordur, ancak her iki kullanıcı arabiriminiz (MVC ve API) tarafından kullanılabilen varlıklarınızı ve depolarınızı kapsayan bir uygulama hizmet katmanına sahip olmaktan yararlanacağınız anlaşılıyor.
David Peden

9

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.


4
Peki @Dimi, bu biraz oy almak için gereksiz bir düzenleme ... Bunları nasıl reddedebilirim?
CularBytes

Ne istiyorsan onu yap. Oylarla düzenlemiyorum ama en iyi görünüm için varsayıyorum. Devam et.
DmitryBoyko

3
@CularBytes Düzenlemeleri reddedemezsiniz, ancak yeniden düzenleyebilir ve değişiklikleri geri alabilirsiniz. Bu, 2.000 temsilcinin altında bir hakem incelemesi süreci gerektirir, ancak bunu anında yapmak için yeterli temsilciniz var. Düzenlemenin hiçbir değer katmadığını ve sizin için geri döndürdüğünü kabul ediyorum.
Dan Bechard


5

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.


2

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.


1
Ayrı projeler istemek için ana gerekçem, API'nin gerçekten ön uç olmamasıdır. Orta kademe.
lordcheeto

6
"Bir aceminin anlaması zor olurdu" bir yaklaşımı diğerine tercih etmek için harika bir neden değildir. Elbette mümkün olduğunda basit tutun, ancak karmaşık ihtiyaçlar genellikle karmaşık çözümler gerektirir. Yeni başlayanlara hitap etmek için aptal kod yazmak yerine, yeni başlayanları akıllı kodu anlama ve yazma konusunda eğitmeliyiz.
Dan Bechard

0

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.


0

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.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.