Przeprowadzka z tradycyjnej ASP. NET MVC do WebApi + Knockout

Question

Właśnie przeczytałem interesujący artykuł o tym, jak Microsoft zmierza w stronę interfejsu REST + opartego na javascript, opartego na javascript, rozwoju MVVM dla aplikacji internetowych.

Chociaż technicznie rozumiem podstawową różnicę między tymi dwoma modelami, jestem całkowicie zdezorientowany, jeśli chodzi o jej implikacje dotyczące tego, jak piszę aplikacje internetowe i co najważniejsze, jak z wdziękiem przejść do tego nowego modelu.

Więc dla kogoś poruszającego się od tradycyjnych ASP.NET MVC do WebAPI + KO, pojawiają się następujące pytania:

• Czy istnieje sposób na dyskretne lub prawie niezauważalnych (tj minimalne Kod potwierdzenia przy użyciu MVC) + KO?
• W jaki sposób jednostka testuje swój kod UI?
• Czy w przypadku KO występuje problem z kompatybilnością przeglądarki?
• Czy jest coś jeszcze, co ktoś musi wziąć pod uwagę, przechodząc z jednego modelu do drugiego?

Answer 1

Widzisz Microsoft zaczynają naciskać tej „jednej aplikacji web page” rzeczy częściowo, ponieważ może zapewnić lepsze doświadczenie użytkownika, ale w dużej mierze dlatego, że sprawia, że ​​o wiele łatwiej jest przenieść swoją aplikację do bycia Windows 8 natywna aplikacja .

Re: dyskretny javascript do sprawdzania poprawności ... Powiedziałbym, że jeśli używasz Knockout, jesteś interfejsem użytkownika, a twoje skrypty będą tak ściśle powiązane, nawet dla podstawowych rzeczy, których dyskretność nie jest naprawdę ważnym celem. Można to zrobić w walidacji Knockout (patrz https://github.com/ericmbarnard/Knockout-Validation#readme na przykład), ale to nie jest dyskretny przez tę samą definicję jak ASP.NET MVC

Re: testów jednostkowych ... przyjrzeć https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit

Re: przeglądarki COMPAT. Nie mam informacji o żadnych problemach ze zgodnością z żadnymi nowoczesnymi przeglądarkami, chyba że masz szalonych użytkowników, którzy wyłączyli JavaScript

Answer 2

Znalazłem this, aby być naprawdę miłym omówieniem plusów i minusów próbowania "dyskretnego" z strona Knockout.

Tradycyjnie jestem zwolennikiem utrzymywania Javascriptu jako dyskretnego, jak to tylko możliwe, a przy moich wyrażeń typu Knockout staram się utrzymywać je możliwie jak najmniejsze i uporządkowane, przenosząc ciężki urywek do funkcji na moim modelu widoku i tworząc własne powiązania, które zawierają logikę DOM - ale jestem głęboko przekonany, że samo podejście deklaratywne (takie jak domyślne użycie atrybutu "data-bind"), gdy jest używane rozsądnie, jest drogą do zrobienia.

Być może to dlatego, że moje wprowadzenie do Knockout to "port" aplikacji internetowej, nad którą pracowałem, a powiązania Knockout mojej strony stają się zaskakująco bliskie odpowiednikom XAML, ponieważ uczę się więcej o tym, jak wykorzystać Knockout wdzięcznie. Po prostu uwielbiam być w stanie przyciągać znaczniki i widzieć na pierwszy rzut oka prawdziwą logikę biznesową związaną z oceną widoku, a nie specyfikacją tego, jak jQuery lub cokolwiek fizycznie buduje to w odpowiedzi na pewne zdarzenie kliknięcia połączone w wielką duszę niszczącą Javascript plik.

Kiedy ponownie odwiedzam niektóre z moich tradycyjnych witryn MVC, które wykorzystują wiele proceduralnych jQuery, aby je połączyć, myślę, że tak, znaczniki są uporządkowane, ale wracając do niego po 6 miesiącach nawet ja mam trudności ze zrozumieniem, co miałem na myśli. z tymi wszystkimi selektorami jQuery, wywołaniami zwrotnymi i przewijaniem DOM. Sądzę, że skuwałbym dynamicznie tylko wiązania Knockout, gdybym musiał, tj.gdyby istniała sytuacja, w której moja logika powiązania byłaaby sama w sobie dynamiczna - ale i tak prawdopodobnie można by to osiągnąć inaczej za pomocą dynamicznych szablonów.

To jest moje 2 centy na dyskretnym aspekcie twojego pytania, a jeśli twoje doświadczenie przechodzenia na MVVM Javascript jest podobne do mojego było w ciągu ostatnich kilku miesięcy, nie spojrzysz za siebie.