Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been using MVC for over a year now, and I like it alot. I've heard of Knockout.js. How is the comparison between these two? Which is better?
MVC seems to have reached its maturity with MVC5, with alot of support.
I do not see knockout.js as well supported. There examples on their site do not even work in Firefox. However, I can see the potential of this since it is written in javascript, client-side, and possibly faster since its client-side, like ajax.
What are the advantages of Model-view-controller vs Model-View-View-Controller?
You should not be comparing Knockout.js to Asp.NET MVC. The only similarities are that they both use the same Model-View-Controller pattern.
Knockout.js:
Knockout is a standalone JavaScript implementation of the Model-View-ViewModel pattern with templates. The underlying principles are therefore:
a clear separation between domain data, view components and data to be displayed
the presence of a clearly defined layer of specialized code to manage the relationships between the view components
The latter leverages the native event management features of the JavaScript language.
Asp.NET MVC:
ASP.NET MVC allows you to build a web application as a composition of three roles: Model, View and Controller.
A model represents the state of a particular aspect of the application. A controller handles interactions and updates the model to reflect a change in state of the application, and then passes information to the view. A view accepts necessary information from the controller and renders a user interface to display that information.
As you can see Knockout.js is an MVC implementation for JavaScript while Asp.Net MVC is an MVC implementation for a complete web application from front end to server. These technologies can even (and very often) be used together to build well structured applications on both the front end and the back end.
You are comparing apples and oranges...
Since you are now familiar with ASP.Net MVC (and the MVC design pattern in general), it is time to take the next step and use a JavaScript MVC framework WITH it.
There are many choices, some popular ones include Knockout.js, AngularJS, Backbone.js, Ember.js, and many more. The site TodoMVC will give you a flavor of what is out there.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We're planning to build a web service to retrieve and send data to an external application.
Someone suggested we use the ASP.NET MVC project. Thing is, we won't have a view. All we're doing is a query and returning the output to the caller. I questioned the use of this project.
He responded that you don't need a view to utilize a MVC project. He added that we can take advantage of the URL routing feature. However, I'm still skeptical.
Is there any reason to choose ASP.NET MVC over a Web API considering we won't utilize the View?
You aren't required to use views (or models for that matter) in MVC. In this case both MVC or Web API would work equally well. There is no advantage of one over the other if you are not using views.
Do note that in ASP.NET Core there is now no difference at all - there is only 1 framework to use and it can be used with or without views.
If you are really want to make some service it's most probably helpful when you use web API. True, it's not necessary to have views in asp.net MVC and also routing is working more similar in both.
The thing is, if you need to authenticate the calls there is little difference how we authenticate calls. Normally web API has come with token-based authentication rather than using cookies use in asp.net MVC.
For your current requirement, the best solution is WebAPI.
You should use MVC controller if you are going return a view. You can return data also from MVC Controller, but is better to user WebAPI controller if you wish to return only data(you can use it like a HTTP service).
The Advantage of using WebAPI is I can say it is a light weight. Hence you can go with WebAPI
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have developed applications using .net MVC with razor view engine.
Recently I was going through knockoutjs being used for MVC applications.
From a 10000 feet bird's eye view , I see that both the approaches have the similar two way binding mechanism .
In the first approach razor syntax for binding the model and in the second we use the knockout data-bind attributes.
My understanding is , why is it that many people are nowadays preferring Knockout and all the buzz recently . Is there any major advantage of replacing razor syntax over knockout library?
They have nothing to do with each other.
ASP.NET MVC
As its name says, it uses MVC (model view controller) technology. That means that you have a model (all the business logic), that can be used to create view models to render the views (by using the razor template). The browser can post data to the controller, and the controller will usually answer by creating a new view model to render a new view, and send it as response to the browser.
So this technology basically uses the browser to send GET or POST requests to the server, and the server answers with rendered views. It can do it directly, or using AJAX. (ASP.NET MVC is much more versatile and can do much more than rendering views, but this is the basic idea).
So ASP.NET MVC involves the server in all operations: it must instance and use a controller, execute an action and send its result as response to the browser.
Knockout
This technology is completely different, in several regards:
it uses MVVM, which consist in a double-way binding between a view (HTML) and a model (JavaScript object). A change in any of the ends is applied automatically on the other end.
it happens on the client side, without using or depending on server resources (as far as it concerns Knockout)
it usually doesn't involve heavy business logic, but simple view models that can show and get data from the user.
This is all what Knockout can do for you. If you need to involve the server, and "heavy" business logic, you need to communicate with the server by sending and receiving objects, which you usually do in JSON format by exposing Web API services. (These services are usually implemented with ASP.NET Web API, but can also be implemented with ASP.NET MVC actions with JSON results, which it's a worse option).
Conclusions
So ASP.NET MVC involves the continuous use of controllers and communication between browser and server, while Knockout is a pure client side technology that doesn't need the server at all. Naturally, to make a Knockout application useful you usually communicate it with the server.
OTOH, Knockout allows to create a Single Page Application, which is a JavaScript application that can run by itself, without loading new full pages from the server, and which usually communicates with services, in the form of Web APIs. One advantage of this is that the application can work even without a server on the other side, and is much more responsive, because it doesn't depend on comminucating with a server to refresh the view.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am working in Asp.net MVC for last 1 year but I have never used AngularJs , BackboneJs or KnockoutJs . Now I want to use it in my project but I am little bit confuse that for MVC which is one is Best . Somewhere I read that AngularJs has best perfomance but mostly used with MVVM framework so kindly provide me proper guidance that with Asp.net MVC which js is best either AngularJs or BackboneJs or KnockoutJs ?
Thanks in Advance.
If you are building single page application you need a SPA framework. It should include two-way data-binding, client-side routing, page composition, navigation, screen state management, module system, bundling. You can choose between Angular and Durandal. They both provide very similar functionality, but in my opinion, Durandal is the most complete SPA framework, which is very easy to use. Both Durandal and Angular can be used with Breezejs to build data centric applications.
check Durandal, Durandal Auth and HotTowel Angular
If you are building ASP.NET MVC application, then all you need on the client side is two-way data binding to reduce DOM manipulations. In my opionion, it's an overkill to use angular just for data-binding. Backbone or Knockout are good choices, but Angular can be used as well.
It depends on the nature of your application. And since you did not
describe it in great detail, it is an impossible question to answer. I
find Backbone to be the easiest, but I work in Angular all day.
Performance is more up to the coder than the framework, in my opinion.
Are you doing heavy DOM manipulation? I would use jquery and backbone
Very data driven app? Angular with it's nice data binding
Game programming? none, direct to canvas, maybe a game engine - Source
Also, take a look at https://stackoverflow.com/questions/5112899/knockout-js-vs-backbone-js
You can check the following source. It's really complete:
http://www.infoq.com/research/top-javascript-mvc-frameworks
Personally, I'd go for Angular just because of its performance, but there are plenty of reasons...
I'm using Knockout with ASP.NET MVC/Web API at work, but I have played with Angular at home and honestly prefer that. Bear in mind though that Knockout solves a much smaller problem than does Angular, the latter being a complete SPA framework (with services, HTML directives etc). To compare apples to apples, you should consider Knockout in tandem with Durandal, as this is a full-blown SPA framework like Angular.
From practical experience I suspect that memory leaks are easier to avoid with Angular than Knockout, since Knockout produces references implicitly as you subscribe to observables (typically via ko.computed) and we had a very hard time trying to track down such memory leaks due to undiciplined taking of Knockout subscriptions without cleaning up. With Angular I couldn't see that you have the same problem, as you don't subscribe directly to mutating variables ("observables"). Instead, the framework is in full control of applying model changes, which might be harder to grasp initially, but ultimately leads to better maintainability.
I have not tried knockout or backbone. With Angular I have worked with ASP.NET MVC. I personally did not like using MVC views. As Angular requires POJO (Plain Old JavaScript Objects) , So, I changed to Web Api and Angular. To be honest I am very satisfied with Angular because of following reasons:
DOM maniuplations are done where they belong.
Two way binding
Designed with unit testing
Services are where they belong
Designed with HTML5 in mind
Ability to create HTML markup to suit business needs (directives) and many more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been in some discussions lately and the talk is about moving over to ASP.NET MVC and Knockout for future work on a product that is currently ASP.NET web forms. This product has many of the characteristics of the general current definition of a SPA.
I've never quite seen how MVC actually fits in when you start generating all your views with JS view models which get their data from calls to JSON web services.
Is there a "sweet spot" that leverages the best parts of Knockout w/JS models and JSON and the MVC framework?
Here are some things that I've been thinking about this (a little random - just seeing if I can spur on some discussion/answers):
When would you use Knockout vs. Razor? Knockout generates the view elements at run time on the client browser. Razor runs as part of the server request before the client receives the response. Are there times that one is clearly better than the other or does it come down to personal taste?
Is there value in keeping more code under the guise of C#/Razor for the purpose of code completion? Also, when exceptions get thrown, stack tracing to compiled code seems easier than JS debugging.
Is it better to completely separate the view from the back-end by creating a blank ASP.NET application and an independent Web API project?
Lots of great questions, I'll share some of my thoughts on the subjects. (Questions have been paraphrased):
1) Is there a place for MVC in a Knockout world? - Absolutely. MVC is a lot more than just Razor. Server side routing, Areas, Authentication, and more, are all provided by MVC. So in my mind, I can still use MVC for all the "admin and organization" but still have all my Views be primarily (but not necessarily completely) AJAX driven. I have discussed using MVC and KO together on SO before. I also have a video dedicated to that topic at WintellectNOW dot com.
2) When should I use Razor? - Let's actually switch up the terminology. It really isn't about Razor vs. Knockout: it's really about server-side vs. client-side rendering.
So when should you use server-side rendering? One ideal time for this is when you are loading data that only has to be done once when the page is initialized. For example, if you have a list of States for a drop down, and that list is extremely unlikely to change, go ahead and load that on the server side. Why turn around and make another request back to an API in that case? I would reserve those calls for dynamic or context sensitive data.
3) Is there value in keeping more code in C# for tooling purposes? - IMHO, no. It's true that debugging JS can be painful, but that is not enough justification for me to disregard all the awesome things I can do client side. It's worth the occasional frustration to provide a better user experience.
4) Should I move Web API to a different project to keep the code separate. - It completely depends on the needs of the project. If the Web API project is going to service multiple applications, then YES it should be in a separate project. That will also put it on a separate DOMAIN, SUB, PORT, or something to differentiate it from the rest of the Web app. Doing so introduces Cross Origin Resources Sharing (CORS) issues. CORS is a particular hell I wouldn't go through unless absolutely necessary. If your Web API is only going to service your single web app, do yourself a favor and keep it in the same project.
As with everything else, a lot of this comes down to personal preference. Mine is to use Server side for managing the bigger picture of my app, and client side for all the UI/UX.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I started building an asp.net webform application. Gradually, I moved all the presentation logic to javascript. I removed all the postbacks and replaced those with calls to web services that receive, process and return json data. I use javascript to generate HTML based on the json I receive from my web services: no gridview to generate tables, everything is generated on the page.
I'm at the point where the aspx pages don't have any code behind any more. I moved all the logic into code libraries in my AppCode folder. I'm not using the viewstate. I'm left with a master page that uses several literals to inject user data on load; the master page has some code behind to manage this process. The main webform functionality I'm using is membership management: I have one login page and one button on the master page that triggers the log out on postback.
Eventually, the entire front-end will work as a one-page application.
How far am I from having an MVC application? Should I keep the structure of my application as is or is there going to be a benefit to moving to an MVC app?
The main difference between WebForms and MVC in easy terms: in WebForms you essentially call a view ("MyPage.aspx") which has some additional logic/code attached to it. In MVC you call a remote function (action) like "products/detail" which contains logic and decides what to return to the browser (for example a view, but it could be json, javascript or whatever). So according to your description, those "remote methods" would conceptually work well as an alternative to your web services.
But as you're using the web forms part only for rendering the initial web page and use web services for all the rest, I doubt that there wouldn't be that much benefit from moving to MVC now. The new WebAPI could be interesting for you, but if you already have your services in place I don't know if you should move now.
Membership isn't any different between WebForms and MVC, so there's no need to change anything here.
I'd say: if your current design works, leave it at that for now.