co to jest MVVM i czy powinniśmy go używać?

Question

Patrzyłem na wzór MVVM, a konkretnie knockoutjs, a przede wszystkim po prostu sprawia, że ​​się boję. Nie pójdę na długiej tyrady o korzyściach utrzymania struktury, prezentacji i wyświetlania oddzielne, po prostu poprosić (jako przykład): Jaka jest różnica między

<button data-bind="click: someJavaScriptFunction">Something</button> 

i

<button onclick="someJavaScriptFunction();">Something</button> 

i czy powinniśmy stosować do znaczników tak dużą kontrolę zachowania? Choć jest czysty i tak minimalistyczny, wydaje się, że jest to sprzeczne z każdą zasadą programowania internetowego, o jakiej kiedykolwiek słyszałem.

Czy jestem w błędzie?

Answer 1

Twoje jedyne użycie jednej części MVVM - konkretnie widoku - w tym przykładzie kodu, który podałeś powyżej. Powodem użycia Knockout (lub dowolnej innej biblioteki MVVM) jest ułatwienie wiązania twoich widoków do Modelu - Modelu Widokowego - pozwalając w ten sposób przestać pisać dużo kodu standardowego, aby zwrócić wartości z widoku.

widzę dużo wonky JavaScript/jQuery kodu, gdzie ludzie chodzą i używać coś takiego:

var ex = { 
    some1: $('#textbox1').val(), 
    some2: $('#textbox2').val() 
}; 

Problem z tym jest to, że dosłownie pełno w całej aplikacji internetowych i staje się niezwykle uciążliwe utrzymać. Z Knockout wiem, że zawsze, gdy mój widok zostanie zaktualizowany, mój model widoku również zostanie zaktualizowany.

Nie jest potrzebna do każdej aplikacji i nie należy jej używać tylko dlatego, że jest "cool" w użyciu. Oczywiście musi być powód, aby go używać, mój przykład powyżej jest jeden powód i jestem pewien, że jest ich więcej.

Answer 2

Oto bardziej bezpośrednia odpowiedź na twoje pytanie.

W drugim przykładzie chodzi o funkcję, która musi znajdować się w zakresie globalnym (tj. Właściwość obiektu window).

W pierwszym przykładzie odwołujesz się do właściwości bieżącego modelu widoku.

Tak, to subtelne rozróżnienie, ale jest ważne. Jeśli używasz atrybutów na zdarzeniu, możesz odwoływać się tylko do rzeczy istniejących w zasięgu globalnym. Oznacza to, że musisz umieścić wszystko, co chcesz, w zasięgu globalnym, co prowadzi do bardzo niechlujnego kodu.

Jeśli używasz powiązań deklaratywnych, dokładne znaczenie powiązań zależy od kontekstu.

Pomaga myśleć o znacznikach HTML jako bardziej przypadkowych. To, na co naprawdę patrzysz, to uporządkowany dostęp do modelu widoku. Pomyśl o with i forEach jako kontekstach zagnieżdżonych i innych powiązaniach jako ich atrybutach. Relacja między deklaracjami wiążącymi a leżącym u podstaw HTML nagle wydaje się bardziej podobna do pracy z XSLT.

Dwa przykłady: wyglądają bardzo podobnie w przypadku. Jednak podstawowe koncepcje są bardzo różne i powodują, że dane wiążące się z tak mocnymi atrybutami są tak nieprzyjemne.

Powód, dla którego atrybuty zdarzeń na żywo są mile widziane, nie polega tylko na tym, że łączą one logikę ze strukturą. Chodzi o to, że są one słabą próbą zrzucenia dowolnego kodu JavaScript do elementów HTML, co uniemożliwia właściwe enkapsulowanie logiki aplikacji.Atrybuty na zdarzeniu to "haki" niskiego poziomu, a powiązania wydłużają zachowanie elementów.

Wszystko, co powiedzieliśmy, jest możliwe, aby zrobić te same straszne rzeczy, które ludzie zrobili z atrybutami na zdarzeniu, używając deklaratywnych wiązań. Różnica polega na tym, co jeszcze możesz z nimi zrobić. Nie zawsze należy oceniać technologie pod kątem ich nadużywania - wszyscy jesteśmy tutaj dorośli.