Backbone.js'yi ASPNET MVC ile bütünleştirmek mantıklı mı?

Question

Bunları yapı taşları konusunda uzman değilim, ama ilk bakışta bana öyle geliyor:

• ASPNET MVC görüntüleme oluşturabilir ve sunucu tarafında bir uygulama için modeller yönetmek istiyor. Tarayıcıyı, sunucu tarafından sağlanan görünümlerin tüketicisi olan biraz aptal bir sunum motoru olarak görür. Backbone.js, görüntüyü oluşturmak ve tarayıcıdaki modelleri yönetmek için tasarlanmıştır. Sunucu tarafını oldukça aptal REST tabanlı bir sebat motoru olarak görüyor.

Bu, basit bir görünüm gibi görünüyor. Eminim bütün hikaye değil.

Bu iki şeyin entegrasyonu için gerçek fırsatlar nelerdir? Bunu yapmak mantıklı mı? Yoksa mantıklı olması için aralarında çok fazla çakışma var mı?

Eğer birileri bana başvurabilirse, bunun bazı analizlerini veya tartışmasını görmek isterim.

Answer 1

Backbone.js ile konuşamamakla birlikte, ASP.NET MVC ile birleştirilmiş mükemmel etkiyi nakavt ettiğimi söyleyebilirim. Bugüne kadar gördüğüm her ASP.NET uygulaması, istemci tarafı ve sunucu tarafı görünüm oluşturmanın bir karışımını kullanır. Her zaman sunucu tarafı görünümleri oluşturmanın daha uygun olduğu zamanlar olacaktır. Örneğin bir kullanıcının kimliğinin doğrulanıp doğrulanmadığına veya belirli bir izne sahip olup olmadığına bağlı olarak şartlı UI öğelerini kullanın. Bir web anlayışlı kullanıcının, istemci tarafı şablonlarınızı keşfetmesini ve almayıp elde etmedikleri tüm özellikleri öğrenmesini istemeyebilirsiniz. Farklı istemci şablonlarını eşzamansız bir şekilde yükleyerek bu konuya kapılabileceğine emin olabilirsiniz, ya da istemci tarafında oluşturulmuş şablonları oluşturmak için sunucu tarafı kod yazabilirsiniz ... Ayrıca eğer SEO size bir şey ifade ederse, istemci tarafındaki templasyonu (tek başına) elveda.

Bu yüzden tatlı nokta, bence, her ikisi de iyi olan bir şey. Deneyimlerimde ASP.NET MVC'yi her ikisinde de mükemmel buldum.

Neden ASP.NET MVC

• Düzenleri (MasterPages)
• Jilet (tip-güvenli intellisense iyilik ile görünümler)
• ActionFilters (günlük gibi kuralları uygulamak için müthiş nokta, kimlik doğrulama müthiş vb)
• JSON serialization for - return Json(model)
• Model bağlama ve doğrulama
• IoC ve MVC iyi arkadaşları (kazan)
• Doğrulama + yetkilendirme ben düşünemiyorum diğer şeyler
• sürü vardır.

Görüntü oluşturma için istemci tarafındaki bir çerçeve kullanarak, kaçırdığınız tüm gerçekten Razor'dur. Düzenleri bir dereceye kadar kaldırabilirsiniz.

ASP.NET MVC ile geliştirmeye aldığım yaklaşım, uygulamanın sunucu tarafında çalışarak başlatılmasıdır. Bu, URL yapınızı, bir denetleyiciyi hak eden, rotalarınızın ne olmasını istediğinizi düşünmeniz için sizi zorlar.Ayrıca, görünümlerin ilk yinelemesi sırasında tür güvenliği ve otomatik tamamlama avantajını elde edeceğiniz anlamına da gelir. Bu alıştırmanın sonunda, Google'ın yeterince yararlanamadığı, insan tarafından bilinen herhangi bir cihazda çalışan basit, standartlara uygun bir çözüm (umarım) var.

Daha sonra istemci tarafındaki işlevsellik dilimlerini uygulamak için artan bir yaklaşım kullanmayı seçiyorum. İstemci tarafında bir AJAX isteğine dönüşmek istediğim bir isteği kaçırmak ve Razor görünümünün çevrilmiş bir sürümünü kullanarak yanıtı ele almak için javascript yazıyorum. Sunucu tarafında bir eylem filtresi kullanarak sözleşmeye dayalı bir yaklaşım benimsiyorum. Bu eylem filtresi, aşağıdakine benzer:

• ActionResult, bir ViewResult mı?
  • Kabul türü nedir?
    • HTML - "_" Aynı modeli
    • JSON verilen öneki aynı adı taşıyan bir PartialViewResult dönüş - Bir JsonResult Dönüş aynı modeli
• ActionResult bir RedirectToRoute sonucu mudur verilen ?
  • Dönüş EmptyResult (veya isteğe bağlı olarak bir JsonResult URL'yi geri dönebilirler) Sulama içinde tek bir kod satırı değiştirmeden AJAX işlevler ekleyebilirsiniz Bu yaklaşımla

. Alternatif bir yaklaşım, Thunderdome Principal'u takip etmek ve modele, talep bağlamına göre uygun bir sonuç türünde sarılmasından sorumlu bir ActionInvoker'e sahip olmaktır. Sunucu tarafı navigasyonunun (yönlendirme) bu yaklaşımla nasıl uyum sağladığını anlamadım.

Sunucu tarafındaki bir uygulamadan başlayarak atık görüntü oluşturma kodu (Jilet + js tabanlı şablon) görünümünde iki katına çıkıyorsunuz. Uygulamanızın ne kadarını müşteriye uygulamak istediğinize bağlı olarak, bu bir sorun olabilir veya olmayabilir. Spark, bunun sizin için generate client templates'a ulaşmasını sağlayan istisnadır! Kıvılcımın olumsuz tarafı, (bunun için bir eklenti var ama onun saçmalıkları) önemsiz bir kayıp değil, sadece Razor'u tercih ettiğimi (fırında pişirilmiş, yapılandırılmaya gerek yok ve her zaman gitmiyor) yakında).

Answer 2

Farklı projeler için asp.net mvc KO ve baklava kemiği kullandım ve sonuçta projenin doğasına iner. İş akışlarınız karmaşıklaşmaya başladığında veya basit veri veri merkezli uygulamalarından farklı olarak UX sunacak olursanız, sunucu yığını kutunun dışına çıkmaz. Projeniz büyük UX omurgaları içeriyorsa, oraya ulaşırsınız. Dezavantajlı şey, iyi şeyler yapmak için blogların cehenneminden geçmeniz gerekecek iyi tanımlanmış bir merkezileştirilmiş kurallar yoktur. Geleneksel uygulamalar için KO'ya sadık kalabilirsiniz. Btw o backbonejs için KO alay edebilirsiniz eklentileri vardır. Ben tekrar kendiniz için entegre olması gerekir bacjbone.modelbinder atıfta Cuz MS hiç rahatsız etmeyecektir.