MVC uygulamasından Web API'sini aynı çözümde aramalı mıyız?


33

Mobil uygulama olan MVC'de bir proje üzerinde çalışıyorum, bu yüzden bir şey mobil uygulamada kullanabilmek için Web API kullanmamız gerektiği açık.

Web sitesini geliştirmeye başladığımızda API oluşturduktan sonra kafamız karışır ve API kullanıp kullanmama konusunda veya Business nesnesine doğrudan erişim konusunda tartışmalar yaptık. Ve, doğrudan Business nesnesini kullanmak yerine Web API'sini kullanmak için daha deneyimli bir geliştirici fikrinin oluşmasından sonra sona erdik.

Bu çözüm yapısına ilişkin kafam karıştı.

1) Neden Web API kullanmalı ve doğrudan aynı çözümde olan iş nesnesi yerine veri almak veya koymak için HTTP isteğinde bulunmalıyız (zaman alıcı).

2) Argümanları aldıktan sonra, müşterinin API ve web'i farklı bulut sunucularında barındırmak ve ölçeklendirmeyi sadece API'ye uygulamak istediğini veya API ve Web'e erişmek için farklı bir URL'ye sahip olmak isteyip istemediğini (bazıları mantıklı olanı) söylediler. Öyleyse bu durumda MVC uygulamasından Web API'sini aynı çözümde aramalı mıyız?

3) API ve Web'i farklı bir barındırmada barındırıyorsak, Web'iniz WebClient'i kullanacak ve her gezinmede HTTP çağrısı yapacak demektir. Doğru mu?

4) Eğer farklı bir sunucuda hem API hem de Web barındırma iş nesnesini oluşturacaksak, BL'da bir değişiklik yapılması durumunda her iki sunucuda da güncelleme yapılması gerekir.

5) Veya API için sadece bir proje oluşturmalıyız ve Web arayüzünü geliştirmek için görünümler veya html sayfaları ekleyebiliriz, böylece API'yi doğrudan ajax'dan çağırabiliriz.

Bildiğim kadarıyla # 5 en iyi çözümdür veya API sadece 3. taraf erişimi içindir. Aynı çözümde DB, EF, veri katmanı ve iş katmanı varsa, HTTP çağrıları yapmak ve iş nesnesine doğrudan erişmek için API kullanmamalıyız. (yanılıyorsam düzelt beni) Mobil uygulama veya masaüstü veya herhangi bir uygulamaya erişmek istediğinde API gereklidir, böylece aynı depoya ve veri katmanına sahip olabiliriz.

Senaryomda mobil uygulamamız olduğu için API oluşturuyorum ve proje API tarafında iş katmanı (ayrı proje) ve iş katmanı veri erişim katmanıyla (ayrı proje) iletişim kuruyor. Dolayısıyla benim sorumuz API ve web'i farklı sunucularda barındırıyorsak, o zaman bir HTTP isteği olan API'yi çağırmak, projeyi oluştururken iş katmanından yöntemi kullanmak yerine daha uzun sürebilir ve iş katmanını .dll yaptık. API denetleyicisinde işimizi sadece json formatına çeviriyoruz.

İnternette aradım ama ikna edici bir cevap alamadım. Bir blog buldum http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx aynı noktayı tartışıyor ama yine de Bu blogda sorum şu: 3. senaryoyu neden düşünmemiz gerekiyor?

Güncelleme: Farklı API projelerine ve MVC projelerine sahip olabiliriz ve API'yi jvascript kullanarak web'den arayabilir veya MVVM şablonunu kullanabiliriz.


Görünüm modelleri ile MVVM veya MVC?
Andrew Hoffman,

Biz MVC kullanıyoruz
Ruchir Shah

Tamam o zaman, doğru bir cevap yok. API’nizi yalnızca kalitelerini artırma konusunda aramanın faydaları vardır. (kendi köpek yemeğinizi yemek) Servisleri çağırmak yerine, gizli aramalar yapmanın performans avantajları da vardır.
Andrew Hoffman

Google bir kez bu soruyu geçti. Ürünleri hem hizmetler hem de web siteleridir. Web sitelerinin kendi hizmetlerini tüketmelerine karar verdiklerine inanıyorum.
Andrew Hoffman,

2
Evet. programmers.stackexchange.com/questions/148556/… ve stackoverflow.com/questions/3590561/… iyi kaynaklar. Bazıları yapar, bazıları yapmaz. Gerçek 'doğru' yol yok.
Andrew Hoffman,

Yanıtlar:


37

Harika soru! Projelerimi yapılandırmak için her zaman daha iyi bir yol arıyorum. Aldığınız her noktaya değinmek ve çeşitli çözüm yapılarını araştırmak, burada yorumların çoğunluğunu kabul ettiğimi söylemek zorundayım: mükemmel bir çözüm yok. Bu tür bir sorunla karşılaştığınızda kendinize sormanız gereken birkaç şey: Bu uygulama ne kadar karmaşık? Ne kadar sistemle entegrasyona ihtiyacım olacak - veya bu sisteme ne kadar sistem entegre etmek gerekecek? Ne kadar test yapmayı planlıyorum? Ayrı bir tasarım / UI ekibi var mı? Ölçeklememiz gerekecek mi? Bir oturumu ne oluşturur?

Bazı senaryolara ve olayların gerçekten çarpışması için biraz zekice bir mühendislik kullanmanın yollarını ve bazı şeyleri biraz daha kolaylaştırmak için bazı hilelere bakalım.

Hem API hem de Web Sitesini Aynı Projede Barındırma
Bu durumda, sıfır veya daha fazla iş katmanı projesi ve tek bir hibrit MVC / WebAPI projesi (ve diğer projeler - yardımcı program, vb.) İle tek bir çözümünüz olabilir.

Pro'nun
Her şeyi tek bir yerde .. Karmaşık mesajlaşmada ayakkabı kornasına gerek yok (HttpClient çağrıları), paylaşılan oturum durumunu (çerezler üzerinden istemci ve sunucu, InProc / OutOfProc oturumu vb.), Bağlantı havuzu oluşturma, paylaşılan mantık vb. Dağıtım daha kolay olamazdı.

Con'ın
Her Şey tek bir yerde .. Bu muhtemelen mümkün olan en monolitik yapıdır. Senin katmanları arasında tanımlanmış arayüzler hiçbir açıkça vardır .. Sen ile bitirmek yüksek uyum . Tembel geliştiriciler, test etmeyi çok büyük bir acı kılan bu tür mimariyle uğraşırken arayüzlerden kaçınırlar. Uygulamanın ölçeklendirilmesi / birlikte konumlandırılması zor olacaktır.

Kullanım Alanları
Bu proje yapısını bir kereye mahsus, dahili veya basit bir uygulama için kullanırdım. Yerel Y'de basketbol kampına kaydolmayı izlemek için hızlı bir sistem kurmak? Bu senin mimarın!

WebAPI ve Farklı Projelerde Web Sitesi
Bu durumu tercih etme eğilimindeyim. Bir (veya daha fazla) MVC projesi ve bir WebAPI projesi ile tek bir çözümünüz var.

Pro'nun
Modülerleşmesi! Gevşek kavrama! Her proje tek başına durabilir, ayrı ayrı test edilebilir ve farklı şekilde yönetilebilir. Bu, gereksinimlerinize bağlı olarak farklı önbellekleme stratejilerini daha kolay uygulamanıza olanak tanır. Farklı sistemleriniz arasında sağlam sınırları koruyarak, belirli kullanım modellerini uygulamanıza ve olası sürtünmeyi azaltmanıza olanak tanıyan sözleşmeleri daha kolay oluşturabilirsiniz (okuma: API'yi kötüye kullanma imkanı daha az hatayla). Ölçekleme biraz daha kolaydır, çünkü yalnızca yüksek yük gören bitleri ölçeklendirmeniz gerekir. Entegrasyon da işlemek için biraz daha kolay hale geliyor, çünkü API'nizin neye benzeyeceği hakkında bir fikriniz olması gerekiyor.

Con'ın
Bakımı biraz daha zor. Vb birleştirme, sözleşmeler (arayüzler), dağıtımlar, Kod bakım, takip etmek, proje / özellik sahiplerini gerekecektir Çoklu projeler vasıtası teknik borç , hata izleme, devlet yönetimi - onlar gerekebilir gibi tüm haline kaygıları farklı uygulanır dayalı olması ihtiyaçlarınız üzerine. Bu tür uygulamalar aynı zamanda büyüdükçe en fazla planlama ve iyileştirme gerektirir.

Kullanım Alanları
Bugün 100 kullanıcısı ve gelecek hafta / ay 100.000 olabilecek bir uygulama oluşturmak? Uygulama bildirim göndermek, karmaşık iş akışlarını yönetmek ve birden fazla arayüze sahip olmak zorunda mı (web + mobil uygulama + SharePoint)? Elleriniz üzerinde çok zamanınız var ve hafta sonu boyunca 5000'den fazla parça bulmacayı çözmeyi seviyor musunuz? Bu sizin için mimarlık!

İpuçları
Yukarıdakileri ana hatlarıyla belirledikten sonra, bir sonraki projenizin biraz korkutucu görünebileceğini anlayabilirim. Endişeye gerek yok, işte yıllar boyunca öğrendiğim birkaç püf noktası.

  1. Vatansız oturumları kullanmaya çalışın. Daha küçük sistemlerde bu, en azından geçerli kullanıcının dahili kimliğini ve zaman aşımını içeren şifreli bir çerezin saklanması anlamına gelebilir. Daha büyük sistemler, bir veri deposundan (redis, tablo saklama, DHT , vb.) Alınabilecek basit bir oturum kimliğine sahip şifreli bir çerez saklamak anlamına gelebilir . Ana veritabanına gitmek zorunda kalmayacak kadar bilgi saklayabilirseniz Her istek üzerine o zaman iyi bir yerdesiniz - ancak çerezleri 1k altında tutmaya çalışın.
  2. Birden fazla modelin olacağının farkında olun. Modeller ve projeksiyonlar açısından düşünmeye çalışın (burada bulduğum bağlantılar .. iyi değildi .. düşünün: bir erkeğin envanter kalemi başka bir erkeğin sipariş satır öğesidir - aynı temel yapı, ama farklı görüşler). Bazı projeler, her bir mantıksal / kavramsal sınır için farklı bir modele sahiptir (örneğin, belirli bir API ile iletişim için belirli bir model kullanma).
  3. API's Her Yerde! Bir nesne / sınıf / yapı herhangi bir veri veya davranışı ortaya çıkardığında, bir API oluşturuyorsunuz. Diğer API'lerin veya bağımlılıkların bu API'yi nasıl kullanacağına dikkat edin. Bu API'yi nasıl test edebileceğinizi düşünün. Bu API ile ne konuşabileceğinizi (kod ile diğer nesneler? Protokol ile diğer sistemler?) Ve bu verilerin nasıl ortaya çıktığını (güçlü bir şekilde yazılmış? JSON? * Öksürük * XML?) Düşünün.
  4. Sahip olduğun şeyleri inşa et, bundan iki yıl sonraya kadar sahip olacağın hayallerini değil. Başka bir cevap YAGNI'ye atıfta bulunuyor - kesinlikle haklılar ! Hayali problemleri çözmek, teslim tarihinizi hayali kılar. Yinelemeleriniz için sağlam hedefler belirleyin ve onlarla tanışın. Dağıtmak! Geliştirme aşamasındaki bir proje, tek kullanıcılı bir projedir - siz!
  5. YMMV (Kilometreniz Değişebilir). Burada mutlak olan tek bir şey var: bir sorun var, bir çözüm üretiyorsunuz. Her şey tamamen havada. Yukarıdaki her iki çözüm de vahşi bir başarı haline getirilebilir - ve emme hatası. Hepsi size, araçlarınıza ve bunları nasıl kullandığınıza bağlı. Hafifçe bas, dost geliştirici!

2
Mükemmel cevap! Keşke yazdığın için sana bir şey ödüllendirebilseydim, ama hiçbir şey düşünemediğim için sadece Twitter'ını takip edeceğim. : P
Dan

"şiddetle yazılmış? JSON? * öksürük * XML" Neyi özlüyorum?
Alexander Derck

1
@AlexanderDerck Üç farklı biçimlendirme seçeneğinden bahsediyorum (daha fazla olmasına rağmen). Bu bazen bir ihtiyaç olmadığını söylemek değildir (özellikle dış gruplarla çalışırken) ..
Bobby D

6

İşletme nesnelerinize doğrudan erişmek (denetleyicinizde demek istediğinizi varsayalım) daha hızlı ve kolay olacaktır.

İstemci API ve web'i farklı bulut sunucusunda barındırmak ve ölçeklemeyi yalnızca API'de uygulamak isterse veya API ve Web'e erişmek için farklı bir URL'ye sahip olmak isterse (biraz mantıklı olan)

O zaman onları ayrı ayrı barındırmanız gerekecek ... ama bu bana mantıklı gelmiyor, kesinlikle ikisini de ölçeklendirmek istersiniz. Bu gereksinimi karşılamak için ihtiyacınız olduğuna emin misiniz? Overkill gibi geliyor. YAGNI'yi hatırla - eğer ihtiyacın yoksa, yapma. İhtiyacın olduğunda, yap.

Ben olsaydım, siteyi siteye en uygun teknolojiyi kullanarak inşa ederdim, o zaman (eğer) başkalarının bunu ayrı olarak arayabilecekleri bir hizmete ihtiyacınız olduğunda.


Günlerin sonunda ölçeklemenin önemli olduğu ve endişenin ayrılmasının benim için önemi önemli olduğu konusunda sana katılıyorum. Kolayca yükseltilebilen veya korunabilen teknoloji değiştikçe, katmanlı mimariyi inşa etmek her zaman iyidir. Örneğin, liman işçisi konteyneriyle sarma, gelecekte göz önünde bulundurulması gereken başka bir şeydir.
Ishwor Khanal

4

Şöyle söylerdim; MVC'yi WebAPI'yi HTTPClient üzerinden arayarak tercih edin. "Core dll" mantığını dolaştırmak çok zor ama temel avantajı, genel sisteminizin HTTP üzerindeki etki alanı nesnelerine tek bir noktadan erişebilmesi ... Her zaman ... Müşteri Tarafı Altyapıları (AngularJS vb.) .... MVC’yi başka bir müşteri olarak ele almak daha iyi ... ve ekibinizi API’leri iyi yönetebilmek için iyi bir şekilde uygulayın ...

SIMPE TUTUN. Umarım bu yardım. Teşekkürler..


Bunun neden
oylandığına

Kendi MVC uygulamasından API çağırmanın iyi bir fikir olduğunu düşündüğüm durumum üzerinde duruyordum - ama bundan farklı ve belki de bu mantıktan sunucu mantığından bahseden bir çok sorudan farklı olduğunu düşünüyorum. Benim durumumda, Vue'yu karmaşık UI'ları oluşturup verileri bu API'ye geçireceğim için fikirlerimden arayacağım. Sonra bunun yasal olduğunu fark ettim çünkü benim durumumda aslında sunucu tarafındaki öğelerden bir görünümden çağrılıyor ve herhangi bir kullanıcı arayüzü göz önüne alındığında herhangi bir http araması zaten yapılabiliyordu. Ancak, yalnızca JS ortamlarında çalışır.
Vasily Hall

Arama API'sini doğrudan görüntülemek iyi bir düşüncedir ... ancak MVC Görünümleri Sunucudan üretilir, bu nedenle sunucudan verileri özellikle sunucu işleme için daha uygun olan) kısmi görünümler oluşturmadan önce de işleyebilirsiniz (Görünümler) ... RESS çerçevesi (RESS : Duyarlı Web Tasarımı + Sunucu Tarafı Bileşenleri) .... Ancak MVC'yi tamamen önleyebiliyorsanız, EN İYİ KULLANIM PURE Müşteri Altyapıları (Açısal / ReactJS) ...
Manoj Kumar Bisht
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.