web-gelistirme-sc.com

Knockout JS yerine Knockout MVC kullanmamın bir nedeni var mı?

Başka bir kullanıcı , bazı AJAX gönderme sorunlarını ele almak için Nakavt MVC 'yi önerdi. Biraz okudum ve Knockout JS etrafında bir sarıcı olduğunu görüyorum. Öyleyse merak ediyorum ikisi arasındaki gerçek farklar neler? Knockout MVC bulunduğundan Knockout JS ile uğraşmalı mıyım? Birini diğerine ne zaman kullanırım?

54
dotnetN00b

Knockout MVC, WebForms’un piç çocuğu. Tüm viewmodel yöntemlerini denetleyici eylemleriyle yönlendirir, bu da gerçekleşen her şeyin sunucuya geri dönmesi ve geri dönmesi gerektiği anlamına gelir. Niçin herhangi birinin neden CLIENT SIDE MVVM olması amaçlanan nakavt gibi bir çerçeve seçtiğini ve onu her işlev için sunucuyu çağırmaya zorladığını anlamıyorum.

Ayrıca, bu yöntemlerin sunucuda gerçekleştirilmesi, her işlev çağrısı için tüm görünüm modelinin sunucuya ve istemciye geri gönderilmesi gerektiği anlamına gelir. Bu inanılmaz derecede boşuna.

Nakavt MVC'yi kullanmak, javascript yazmak zorunda olmamanın yararı için müşteri tarafı kodunun tüm performans avantajlarını feda etmek anlamına gelir. Aynı takas WebForms yaptı. Bu iyi değil. Bu bir antipattern.

Nakavt MVC yarın ölürse, web daha iyi bir yer olacaktır.

124
Tyrsius

Ben sadece oldukça olumsuz yanıtları olan bu soruya rastladım. Çabucak iki kuruş değerimi ekleyeceğim.

Daha yeni KnockoutJS kullanmaya başladım. ASP.NET MVC uygulamaları oluşturduğumdan beri, Knockout MVC gibi bir şey kullanmak bana mantıklı geldi. Çoğunlukla, harika bir fikir gibi görünüyor. Eğer bildiğim ve sevdiğim .Net işlevselliğini kullanarak yapabilirsem, sayfalarımda javascript ve <!-- ko --> yorumlarını yazmakla zaman geçirmek istemem.

Bunu söyledikten sonra ... evet, şu anda KMVC için sınırlamalar var. Tüm modeli sunucuya geri göndermek büyük bir tanesidir. Yaptığım şey kendi nakavt-mvc çatalım. Değişiklikler şu anda mutlaka koştu. Ama şimdi yeteneğim var:

  • alt bağlamlar oluşturun (tamamen farklı modeller veya görünüm modelinin bileşenleri ile)
  • sunucu çağrıldığında seçilen model bölümlerini geri
  • bir çağrıdan gönderilenlerden farklı bir model beklemek
  • ajax aramaları çevresinde yangın olayları
  • daha fazla html5 giriş türünü destekler
  • sahtecilik karşıtı belirteçleri sunucuya başlıklarla iletme (ajax çağrıları için)
  • muhtemelen daha fazla unuttum

Yakında geri dönmeyi ve yaptıklarımı gerçekten temizlemeyi umuyorum. Umarım, yazar kodunda bu değişiklikleri içerecektir. Olmazsa, sanırım kendi çatalımı kullanmaya devam edeceğim. Her iki durumda da tünelin sonunda ışık var. KMVC'nin olduğu gibi çalışmaya ihtiyacı olabilir, ancak kavramın kesinlikle yapmaya değdiğine inanıyorum.

Kesinlikle düşünüyorum 

Nakavt MVC yarın ölürse, web daha iyi bir yer olacaktır.

biraz sert oldu.

Düzenle:

Yorumlara bakıyordum ve orijinal sorunun ne olduğuna tekrar baktım. Cevabımı biraz daha eklemek gerektiğini düşünüyorum yaptıktan sonra:

İlk olarak, asıl soru Knockout JS yerine Knockout MVC kullanmamın bir nedeni var mıydı? Cevaplamak/açıklamak (belki de seçici davranıyorum): Knockout MVC bunu yapmak için tasarlanmış bir çerçeve KnockoutJS'i ASP.NET MVC uygulamanıza entegre etmek daha kolay. Bunu çoğunlukla KnockoutJS etiketlerini oluşturmak için tanıdık, kuvvetle yazılmış yapılar kullanarak yapar. Bu KnockoutJS'nin yerine geçmez. Elbette, KnockoutJS kullanın. Buradaki soru gerçekten Knockout MVC 'nin kullanılıp kullanılmayacağı.

Bunu söyledikten sonra, seçim, sizin için mevcut olan tüm araçların çeşitli yönlerini ne zaman kullanacağınızı seçmek için bir geliştirici olarak sizindir. Sunucuya geri tam bir istek gerçekleştirerek işlevselliğin belirli bir yönünü ele almak istiyorsanız, o zaman bunu yapın. Verileri almak/güncellemek için bir ajax isteği yapmak istiyorsanız, bunu yapın. İşlevsellik tamamen istemci tarafında yapmak istiyorsanız, o zaman bunu yapın.

Knockout MVC'yi kullanma /, KnockoutJS'yi sonuna kadar kullanmanıza engel olmaz. Knockout MVC kullanma /, istediğiniz kadar istemci tarafı işlevselliği sağlamak için ek javascript yazmanızı engellemez. Sadece Knockout MVC'nin sunucuya ajax geri çağrıları oluşturmak için bir kısayol sağlaması nedeniyle bu onları kullanmanız gerektiği anlamına gelmez. Her ne kadar, uygulamanız veriye devam ederse de, bir noktada evden aramak zorunda kalacak.

Statik HTML ve betik dosyaları sunmak için Apache kullanmaya kıyasla ASP.NET MVC kullanarak bir uygulama arka ucu oluşturmanın nedenleri vardır. Knockout MVC, KnockoutJS entegrasyonuna yardımcı olmak için aynı avantajlardan yararlanmaya devam etmenizi sağlar.

21
Nigel Whatling

Tyrsius'un cevabını biraz olumsuz buluyorum. Nakavt MVC hala erken gelişme, ancak görebildiğim kadarıyla bazı avantajları vardır ve örneğin Webforms daha az sunucu ağırdır. Görünürlük bağımlılıkları, yalnızca istemcide yalnızca sunucuya bir çağrı yapıldığında işlevler kullanıldığında ele alınır. Karmaşık veri yapılarıyla çalışırken, bazen sunucudan yine de geçmeniz gerekebilir, bu nedenle Knockout MVC, çok fazla Ajax işlemesi yazmaktan tasarruf etmenin iyi bir yolu olabilir.

Her zaman tüm modeli ileri geri gönderdiği doğrudur, bu kendin yapmanın tersine bir miktar ek yük sağlar. Ama tamamen yazmam. Özellikle gelecekteki karmaşık validasyonlar için uygun müşteri tarafında işlem yapıldığında.

13
Erwin

Mvc hakkında nakavt hakkında biraz arama yaptıktan sonra bu yazıyla karşılaştım. Ağ bant genişliği israfını kabul etmeme rağmen, bu kod satırından oldukça etkilendim:

@{
  var ko = Html.CreateKnockoutContext();
 }

Bu, nakavt görünüm modelini oluşturmak için temiz ve temiz bir yoldur. Herkes bu özellik için ve tüm mantığı sunucu tarafına taşımadan MVC nakavtını kullandı mı? 

11
Sam

Knockout.js’nin güzelliği, uygulamanızın, HTML’yi oluşturmak için sunucunun tıkanması gereken bir görünümü zorlamak zorunda kalmadan, JSON'u sunucudan ileri geri geçirerek sunulmasını sağlamaktır. 

Onu tekrar sunucuya koymak çok sezgisel görünüyor! Bu sizi ilgilendirirse, ilk etapta bağlayıcıyı gerçekleştirmek için jilet sözdizimini kullanmaktan daha iyi olursunuz. 

Benim önerim, bağlantınızı yapmak için knockout.js kullanmak olacaktır; böylelikle bağlayıcı, hedeflediğiniz hedef buysa, sunucuda değil istemcide gerçekleşir. Görünümünüzün sunucuya bağlı veri olmasını istiyorsanız, ustura kullanın.

8
OnResolve

Dahası, knockout.js, müşteri tarafında veri görüntüleme/silme/ekleme/güncelleme ve müşteri tarafında veri hesaplamada çok iyidir. Gerçek bir iş mantığı bu kadar basitse, doğrudan knockout.js'yi uygulamamız gerekir.

Gerçek şu ki, iş mantığı böyle her zaman basit değildir. Örneğin, müşteri görünüme yeni bir kayıt eklediğinde, sistemin Kullanıcının kimlik doğrulamasını kontrol etmesi, bazı iş mantığına veya formülüne vb. Dayanarak yeni oluşturulan nesne için varsayılan değerleri ayarlaması gerekir. veritabanı verilerine göre mantık.

Geliştirici, gerekli tüm işletme mantığını knockout.js view modelinde Java betiği yöntemlerine dönüştürebilir. Ancak bu şekilde, tasarım, merkezi iş mantığı işleme kuralını ihlal ediyor.

Böyle bir tasarım için bakım kabus olacak.

Özet, hangi çerçeve seçiminin gerçekten iş gereksinimine bağlı olduğu. Bazen, performans ilk dikkate alınmaz.

6
ChinaHelloWorld

Knockout MVC kütüphanesi ile birçok iyi kullanım örneği de görebiliyorum. Örneğin @ChinaHelloWorld tarafından belirtilen sebeplerden ötürü KnockoutJS'yi MVC web uygulamamıza pek dahil edemedim. İşte son derece yararlı bulduğum bazı durumlar.

  1. Kesinlikle yazılmış ciltler

KnockoutJS'i kurarken tamamen işe yaramaz ve dağınık hale gelen güçlü bir şekilde yazılmış HTML yardımcı yöntemlerini sevdim. Yapabileceğim en iyi şey, bağlayıcı niteliklerimi yardımcı yöntemlerin extra parametresiyle el ile eklemektir, ancak yine de sihirli dizeleri kullanmak zorunda kaldım. Knockout MVC tarafından sağlanan ve güçlü şekilde yazılmış, C # ifadesi temelli ciltlemeli girdiler ve diğer öğeler oluşturmak için sağlanan yardımcıları seviyorum. Ancak, burada ben üretilen alanların ad özniteliğini özlediğimi belirtmek isterim, bu yüzden biraz ayarlamam gerekiyordu.

  1. Kesinlikle yazılan ciltleme sözdizimi (tür)

Saf tel bağlayıcıları kullanırken, her zaman yanlış hecelemek veya uygulamak istediğiniz ciltleme biçimini tam olarak bilmemek için iyi bir şans vardır. Knockout MVC ve VS IntelliSense’in akıcı API'si ile doğru ciltlemelerin uygulanması gerçekten kolaydır.

  1. (Neredeyse) Hesaplanan C # özelliklerinden hesaplanan ciltlere otomatik dönüştürme

Sadece küçük [Hesaplanmış] özniteliğinin uygulanmasıyla, Knockout MVC, doğru KnockoutJS sözdiziminde karşılık gelen bağlama ifadesini üretebilir. Bu bence de çok faydalı.

  1. Görünüm kodu kod çoğaltması yok

Klasik bir şekilde, C # kodunda viewmodel sınıfına ve daha sonra da JS'de (neredeyse gözlemlenebilir) aynı viewmodel koduna sahip olmam gerekiyordu. Bu benim için sinir bozucuydu ve Knockout MVC'de kullanılan tekniği gördüğümde çok mutlu oldum. Ancak, onu gerçekten karmaşık görünüm modülleriyle (iç içe görünüm modülleri, koleksiyonlar, vb.) Kullanabilmek ve biraz eşlemeli Nakavt görünüm modülleri, örneğin gerekli herhangi bir özel JS yöntemiyle veya hesaplanan gözlemlenebilir olanı genişletmek için biraz düzeltmem gerekiyordu. .

Yani burada en az dört çok iyi nokta var. Ve görünüm modelini gezme hakkında: hiç kimse kimsenin Knockout MVC'nin sunucu tarafı işleme mekanizmasını kullanması gerektiğini söylemedi. Bunu da kullanmam, sadece sunucuda gerçekten işlenmesi gereken karmaşık bir iş mantığı varsa. Ancak çoğu durumda, Knockout MVC, yalnızca MVC Views ve KnockoutJS’in ciltleme ve kurulum sürecini kolaylaştırmak içindir. Bu yüzden yukarıdaki kötü görüşleri tam olarak anlamıyorum. Bence bu görüşleri kimin yazdığını, en azından Knockout MVC'nin temel kavramlarını öğrenme çabasında olmadı. Hedefler kesinlikle KnockoutJS yerine Knockout MVC kullanmamalı, ancak KnockoutJS kullanmamalı. Javascript ve en azından KnockoutJS'in temellerini anlamak, her durumda hala zorunludur.

Yazarın Knockout MVC'nin geliştirilmesine devam etmesini diliyorum, çünkü bu iyi noktaların yanı sıra, gerçekten daha da güçlü kılacak bazı özellikler ve ayrıntılandırmalar var.

6
Zoltán Tamási

Net MVC deseninde, zaten her bir görünüme/kısmi görünüme işaret eden görünüm modeli açıkça "@model yourmodel" etiketiyle işaretlendi;.

Knockout.js MVVM şablonunu kullanırken, görünümlerde "data-bind" gibi etiketler dışında herhangi bir .Net view modeli göremezsiniz. Bu, görüntüyü ve denetleyiciyi bağlantısız ve ekipteki yeni bir geliştirici için özel olarak mantığı izlemek zorlaştıracaktır.

KnockoutMVC'nin bu tür zorlukları çözebileceğini ve sistemin korunmasını ve anlaşılmasını zorlaştıracak birçok javascript kodunu kaydedebileceğini düşünüyorum.

NakavtMVC, tasarımın C # kodu olduğu için takip etmesi ve bakımı kolay olan sunucu tarafı görünüm modelini uygulamaya devam etmesini sağladı.

Bir iş projesi için, yönetici her zaman geliştirmesi kolay, bakımı kolay, yükseltmesi kolay ve anlaması kolay ve hızlı bir şekilde para kazanmak için verilmelidir.

Biraz performanstan ödün ver ama basitleştir, müşteri tarafında ve sunucu tarafında tutarlılık önemli bir nokta olmalıdır. Javascript büyük bir bakım konusudur.

Tüm görünüm modelini sunucu tarafına geri göndermek gerçekten bir sorun mu? Olursa, büyük bir modeli birkaç küçük modele bölebiliriz.

4
ChinaHelloWorld

Komvc tarafından oluşturulan işlevleri kullanmıyorsanız yine de performansınız var. Nigel’in dediği gibi, ilk sayfa oluşturma işleminin yine de sunucu tarafından yapılması gerekecekti. Her zaman kullanıcı komut dosyaları ekleyebilir ve istemci tarafında sunucuya geri dönmesi gerekmeyen işlevler oluşturabilirsiniz. Geliştiriciye biraz verimlilik sağlayan bir araçtır. Web formlarıyla yapılan performans karşılaştırması kesinlikle abartılı. Millet, bu, son tarihinizi karşılamanıza yardımcı olacak bir araç. 

2
Jacobian

Nakavt MVC, Javascript olmadan geliştirici dostu fluentAPI'leri kullanarak ve çok sayıda yinelenen ve tekrarlanan kodu kaldırarak geliştirici dostu fluentAPI'leri kullanarak web sitesi istemcisi işlevselliğini doğrudan .NET projenize uygulamanıza olanak tanıyan ASP .NET MVC için güçlü bir eklentidir.
nakavt MVC, ASP .NET MVC ustura kodlamasıyla aynıdır ve istemci işlevselliklerini herhangi bir ek güçlük çekmeden elde edersiniz.
Bir görünüm modelini ve ciltleme kod satırlarını kodlamanız gerekmez.
Web sitelerimin çoğunda koMVC kullanıyorum ve zaman azaltma, kolay bakım ve asal öğrenme eğrisi geliştirme büyük bir kazanç. 
Web sitelerini kontrol etmenizi ve bazı canlı örneklerle devam etmenizi öneririm. http://knockoutmvc.com
Ona aşık olmanız çok uzun sürmeyecek.

1
POM

2 sentimi nakavtların lehine ekleyeceğim, ancak MVC nakavtına kıyasla yazmak biraz karmaşık olsa da, yeniden kullanılabilirlik söz konusu olduğunda alacağınız fayda çok büyük. Müşteri kodu diğer teknolojilerle de uyumlu çalışabilir. 

Güvenlik perspektifini bir kenara bırakmak ben şahsen nakavt js'yi asp.net MVC'yi karmaşıklaştırmanın bir yoludur ve asp.net webapi gibi saf RESTful uygulamalarında olduğu gibi (nakavt js) kullanılmalıdır. 

1
Govin

MVC, Model, Görünüm ve Kontrolör olmak üzere üç bileşene ayrılan bir mimari kalıptır. 

NakavtJS, MVC mimarisiyle en iyi şekilde çalışır çünkü çerçevenin veri bağlaması denetleyicinin kullanılmasını gerektirir. Ön uca daha fazla odaklanan AngularJS gibi çerçeveler var ve bu yüzden MVVM mimarisi modeli ile daha iyi çalışıyorlar (model, görünüm, görünüm modeli). Veri bağlama özellikleri ayrıca ciltleme kapsamını azaltan denetleyici kullanımını gerektirmez.

0
Bbo