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.
Related
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 5 years ago.
Improve this question
I have started learning ASP.Net MVC, I have few questions with regards to MVC framework [Client Side or Server Side]. You might find these questions stupid but I am really confused and would like to clear my doubts.
Here it is....
ASP.Net MVC, is it server side or client side framework?
Let's say my controller methods getting data from the SQL Server, I convert it into JSON and updating the MVC view, in this case
A. Is it called as Client side data binding or Server side binding?
B. While retrieving the data from database using controller method, do i get entire HTML along with data in the response or just the data that I have requested for?
In ASP.Net, lets say I am inserting data in database on button click event and If I am not wrong, in this case it will submit the entire page to the server, how button click event works in ASP.Net MVC?
I have also read that we can use Angular.JS or knockout.JS with ASP.Net MVC, what purpose Angular.JS or knockout.JS would solve if we use it with ASP.Net MVC?
Regards
ASP.Net MVC, is it server side or client side framework?
> MVC - is Model View Controller - its All-in-One
Let's say my controller methods getting data from the SQL Server, I
convert it into JSON and updating the MVC view, in this case
Is it called as Client side data binding or Server side binding?
> Server side is ALL what you do with C# (In class library/controllers etc)
While retrieving the data from database using controller method, do i
get entire HTML along with data in the response or just the data that
I have requested for?
>If you will use knockout / angular - then you need just get data from server, and data-bind will happen automatically
In ASP.Net, lets say I am inserting data in database on button click
event and If I am not wrong, in this case it will submit the entire
page to the server, how button click event works in ASP.Net MVC?
>Or with submit form (to action url) - or with client framework (knockout/angular) - you just send json
I have also read that we can use Angular.JS or knockout.JS with
ASP.Net MVC, what purpose Angular.JS or knockout.JS would solve if we
use it with ASP.Net MVC?
>Angular more rich framework. In knockout we have only data-bind with html. It depends on what you need for your project.
ASP.Net MVC is a server side framework. (An alternative is ASP.Net WebForms: your events are posts to the same page, abstracted to seem like desktop application events.)
If you want, you can output data as JSON or XML and use this with a client side JavaScript framework to update your views.
You will not have button clicks in ASP.Net MVC. All data is sent to the server as parameters in the URL, GET or POST variables (in truth, WebForms also does this). You can grab the values directly from the Request or use the bindings from MVC to get the values as action parameters.
These frameworks are used to build the views in the client side. To use them, you will have to, mostly, output JSON from your controllers.
MVC is a design pattern that you can apply "anywhere" - e.g. server or client side. In ASP.NET MVC, the MVC pattern (model, view, controller) is first and foremost applied server-side, e.g. the code you write executes on the server. (In your view, you can if you like also utilize some MV* pattern, using your own code or a library like Knockout or Angular. This (JavaScript) is then executed on the client, hence client-side.)
Sometimes a piece of code or software that communicates with some other service or similar is labeled a "client", but that is a different context.
Your binding example would execute on the server, if we're talking about ASP.NET MVC Controller code. (In general, there is no need from the framework point-of-view to do any explicit JSON conversion, but that's a different question.)
ASP.NET MVC features something called "model binding" (google it). It's there out-of-the-box, but you can control it with your own implementations as well. Thanks to this feature, you normally deal with strongly typed data inside your Controller.
ASP.NET MVC and Web Forms are fundamentally different. Explaining exactly how, and how to make buttons in ASP.NET MVC that send data is out of scope, but generally we're talking simple POSTed data, e.g. from an HTML form or whatever.
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 9 years ago.
Improve this question
I'm working on an application that will have both web and mobile interfaces. That's why I want to use Web API. I don't have any problem with the Web API part, but I don't know what to do with the MVC application.
As far as I understand, my data access layer and Entity Framework will be in Web API, but I still have to create my Model classes in MVC for things like data formatting and..., data validation will take place in Web API, and I'll use Ajax calls to Web API from my Views in MVC to access data. Now, the question is, what's the role of Controller in MVC then?
Can someone tell me what design pattern should be used to develop an asp.net MVC application that consumes data from an asp.net Web API application?
If you want to leverage the ASP.NET MVC framework you could centralize business logic and data access in service classes that would be used by both your Web API and MVC application. I usually avoid calling Web API from MVC when I own both applications.
On the other hand, if you want to consume your API through ajax requests, you should use a client-side JavaScript framework such as AngularJS. In this scenario, you barely use the MVC framework. Your MVC application will serve the initial view, perform login/logout and optionally bundle and minify js and css files.
Of course, you can chose a strategy somewhere in between. For example, you might not want to dive into the complexity of a single page web application and use jQuery for ajax requests instead. In this case, you might need to use your MVC application as a proxy to your services or Web API to avoid cross-domain issues.
In short, there is no single best design pattern. Here are some factors that could influence your design : budget, complexity, user experience, responsiveness, browsers and targeted users. For instance, it is unnecessary to use cutting-edge client-side technologies for 2-3 users using IE6 to fill endless forms with data.
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.
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.