Is there a reason I would use Knockout MVC instead

Question

Another user suggested Knockout MVC to handle some AJAX posting issues. I read a little on it and I see it is a wrapper around Knockout JS. So I wonder what are the real differences between the two? Should I bother with Knockout JS since Knockout MVC exists? When would I use one over the other?

Answer 1

I can also see a lot of good use-cases with Knockout MVC library. I could hardly integrate KnockoutJS into our MVC web app, exactly because of reasons which were pointed out by for example @ChinaHelloWorld. Here are some cases where I find it extremely helpful.

1. Strongly-typed bindings

I liked the nice strongly-typed HTML helpers methods, which became completely useless and messy when it came to setting up KnockoutJS. The best thing I could do is to manually attach my binding attributes with the extra parameter of the helper methods, but I had to use magic strings there again. I like the helpers provided by Knockout MVC for creating inputs and other elements with strongly-typed, C# expression based bindings. However, here I would like to mention that I miss the name attribute of the generated fields, so I needed to tweak it a little.

2. Strongly-typed binding syntax (kind of)

When using pure string bindings, there is always a good chance of misspelling, or not exactly knowing the correct format of the binding which you'd like to apply. With the fluent API of Knockout MVC and the VS IntelliSense it's really easy to apply the correct bindings.

3. (Almost) Automatic conversion from computed C# properties to computed bindings

Just with application of the small [Computed] attribute, Knockout MVC can generate the corresponding binding expression in correct KnockoutJS syntax. This one is very useful as well I think.

4. No viewmodel code duplication

In the classic way, I needed to have the viewmodel class in C# code, and then (nearly) the same viewmodel code in JS (with observables). Well, THAT was frustrating for me, and I got extremely happy when I saw the technique used in Knockout MVC. However, I needed to tweak it a bit for being able to use it with really complex viewmodels (nested viewmodels, collections, etc.), and to be able to extend the mapped Knockout viewmodels with for example any needed custom JS method or computed observable.

So here are at least four very good points. And about viewmodel round-trips: no-one told that anyone of us need to use the server-side processing mechanism of Knockout MVC. I wouldn't use that either, only if there is some complex business logic which really needs to be processed on the server. But in most cases, Knockout MVC is just for simplifying the binding and setup process of MVC Views and KnockoutJS. So I don't quite understand the bad opinions above. I think who wrote these opinions did not take the effort to learn at least the basic concepts of Knockout MVC. Yout definetely should NOT use Knockout MVC instead of KnockoutJS, but besides KnockoutJS. Understanding Javascript and at least the basics of KnockoutJS is still mandatory in any case.

I wish the author continued the development of Knockout MVC, because besides these good points, there are some features and refinement which would really make it even more powerful.

Answer 2

MVC is an architecture pattern which separate into three component, Model, View and Controller.

KnockoutJS work best with the MVC architecture because the framework’s data binding require the use of controller. There are frameworks such as AngularJS which focuses more on the front end and therefore they work better with the MVVM architecture pattern (model, view, view model). Their data binding features also doesn’t require the use of controller which reduce the scope of binding.

Answer 3

The beauty of Knockout.js is that you can get your application served by simply passing JSON back and forth from the server without having to push an entire view that the server had to chunk away at to generate HTML.

It seems very counter-intuitive to put that back on the server again! If that interests you, you're better off using the razor syntax to accomplish your binding in the first place.

My suggestion would be to use knockout.js to do your binding so that the binding takes place on the client rather than the server if this is the goal you're going for. If you want your view to be data bound on the server, use razor.

Answer 4

I've come across this post after searching a bit about knockout mvc. Although I agree with the waste of network bandwidth, I'm quite seduced by that line of code :

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

This is a neat and clean way for generating the knockout viewmodel. Has anyone used knockout MVC just for that feature and without moving all the logic to the server side ?

Answer 5

More, knockout.js sure is very good at client side data display/delete/insert/update, and client side data calculation. If a real business logic is as simple as that, we must apply knockout.js directly.

The truth is, business logic is not always simple like that. For example, when client insert a new record on view, system possibly need to check User's authentication, set default values for the new created object based on some business logic or formula etc... All this, anyway should go to server side and checking logic based on database data.

Developer is able to translate all required business logic into java script methods inside knockout.js view model. But this way, the design violate the rule of handling business logic centralized.

The maintain will become nightmare for such design.

Summary, what framework choice really depend on business requirement. Sometime, performance is not the first consideration.

Answer 6

I will add my 2 cents in favour of knockoutjs, though it is little complicated to write compared to knockout MVC, the benefit you get is huge when it comes to re-usability. The client code can work harmoniously with other technologies as well.

Keeping aside the security perspective I personally feel knockout js is a way of complicating asp.net MVC and it should be used as is (knockout js) with pure RESTful applications such as asp.net webapi.