Migrating from Traditional ASP.NET MVC to WebApi + Knockout

Question

I just read an interesting article on how Microsoft seems to be moving towards a JavaScript-based REST + interface based on JavaScript for MVVM for web applications.

Although I technically understand the main difference between the two models, I am completely confused about its implications regarding how I write web applications and, most importantly, how to gracefully switch to this new model.

So, for someone moving from a regular ASP.NET MVC to WebApi + KO, the following questions arise:

• Is there a way to have an unobtrusive or almost invisible (i.e. minimal code check) using MVC + KO?
• How to do a unit test of your user interface code?
• Browser Compatibility with KO?
• Is there anything else that someone should consider when moving from one model to another?

Answer 1

You see, Microsoft is beginning to push this “one-page web application” in part because it can provide a better user interface, but in large part because it greatly simplifies porting your web application to its native Windows 8 application.

Re: unobtrusive javascript to check ... I would say that if you use Knockout, you are a user interface, and your scripts will be so closely connected even for basic things that unobtrusiveness is not really a real goal. You can do validation in Knockout (see https://github.com/ericmbarnard/Knockout-Validation#readme , but it's not unobtrusive by the same definition as ASP.NET MVC

Re: unit testing ... look at https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit

Re: browser compat ... I do not know any compatibility issues with any modern browsers, unless you have crazy users who have disabled JavaScript

Answer 2

I found this one to be a really nice discussion of the pros and cons of trying to be “unobtrusive” with the Knockout website.

Traditionally, I am very grateful that Javascript is as unobtrusive as possible, and with my knockout expressions I try to keep them as minimal and neat as possible, shifting any heavy lifting to functions on my presentation model and creating custom bindings that encapsulate the DOM logic, but I am strongly of the opinion that the declarative approach itself (such as the default of using the data binding attribute), when used wisely, is a transition method.

Perhaps because my introduction to Knockout is the "port" of the WPF application I worked for, and the Knockout bindings of my site become surprisingly close to their XAML equivalents, as I learn more about how to use Knockout effectively, I just I like the ability to mark the eyeball and immediately see the real business logic around how the presentation is evaluated, and not the specifics of how jQuery or something physically builds it in response to some click event associated with a big soul that destroys the Javascript file .

When I review some of my traditional MVC sites that use a lot of procedural jQuery to hook them, I think yes, the markup is neat, but returning to it after 6 months, even I find it hard to understand that my intention was with all these selectors jQuery, callbacks and DOM traversals. I think that I would apply the Knockout bindings themselves dynamically if I had to, that is, if there was a situation where my binding logic itself was dynamic, but in any case it could be different in different ways with dynamic templates.

The fact that my 2 cents is on the unobtrusive aspect of your question, and if your experience of switching to MVVM Javascript is something like mine, was in the last few months, you will not look back.