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
As we know, MVC in .Net supports two view engines, namely, ASPX and Razor. I have read several articels and have observed that Razor is unanimously(almost) considered as a better option between the two. The reasons being:
Razor is clean - Agreed. The syntax itself makes it cleaner.
Razor syntax is simple - Agreed. There is no need to close the tags.
Razor is light-weight - I am unable to understand why is it considered light-weight ?
EDIT 1
Other differences:
- The design can be viewed in the ASPX engine while it cannot be viewed in Razor engine.
Also, apart from these differences, are there any other differences which make Razor and ASPX significantly different ?
If I am missing any other basic difference/point here, please point it out since I have been able to summarize only the above after reading several articles.
I think "lightweight" might be a reference to the output from the razor engine: thinking about the output from a traditional aspx forms app the server delivers a page with not only the markup but the viewstate as well, control ids are bulked by effectively a path which describes how they are nested on the page and then there is all the javascript which makes this and things like postback work. In addition updates to the page are more likely to involve a round trip to the server (they needn't but most often they do). On postback the server also has the job of serialising and deserialising not only the viewstate but also instantiating all the controls on the page before you can code against the dom. There are optimisations that you can do but essentially your going to end up with something that looks a bit like this and all of this could be described as heavy - heavy payloads to the client, heavy workload on the server serving the pages and servicing the pages.
In contrast the output from a razor built form can be little more than the markup - simple HTML controls a few hidden fields for key values etc and a button or two. You can add CSS and jquery and dynamic dom manipulation but they aren't essential for making the page: a submit button a form with an action and a method will get your form data back to the server and that's all the server gets a collection of basic encoded form fields. The server will instantiate the expected entity type based on the form fields (it needn't) but that's all it has to do before your coding against the posted data.
In this way the razor model could be considered lighter than the trad aspx way. Even complex pages tend to push the processing to client via javascript/CSS/jquery libraries and ajax communication.
Main advantage of Razor view are :
1) optimized syntax for HTML generation using a code-focused templating approach, with minimal transition between HTML and code
2) Supports layouts (alternative to master page in aspx)
3) Unit testable (Most important in large projects)
4) Supports IntelliSense.
5) The Razor View Engine prevents Cross Site Scripting (XSS) attacks by encoding the script or HTML tags before rendering to the view
6) Razor has a syntax that is very compact and helps us to reduce typing.
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 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 7 years ago.
Improve this question
I will start a new .Net MVC project with a small team. It have five members, two back-end devs and three front-end devs.
The front-end members will work separately, building a html version of this project using tools like gulp/grunt, less/saas, jade and others frameworks. They prefer to use editors like Sublime and will run interface tests in many differents devices in real time.
They not able to work with MVC specifically Razor view engine, so we need two repositories, one to front and another to back.The back-end developer in the process ever need to catch the built html and suit it in Razor MVC.
Any ideas how to improve this process? How can i reduce the technical gap between back devs and front devs?
IMO you are trying too hard to accommodate the skills/desires of your team members. You will not get good cohesion from the client side with the server side if you completely ignore Razor/CSHTML. Your overall architecture/design should come first, and dictate these decisions. Of course you would take your team's skills into consideration, such that you wouldn't make a team of Java developers adopt C++. But you are taking this to an extreme by basically throwing consideration for design/architecture out of the window, and saying you will divide the application based on what your devs are willing to work with.
My opinions aside, you can make this work, but somewhat painfully.
For one, developing HTML apges first in a vacuum without consideration for interactions with the server is either going to result in very crippled interface that is more like static website from the 90s. There are a few cases where you can build a single-page-application that's pure javascript with no AJAX requests, but these scenarios are very rare.
Therefore, you need to either build the server-side first, or have a design step that mocks up the page and talk through how it will work.
1) Design a page and it's features, and how it interacts with the server. Identify what interactions are navigation actions, such as clicking a link to navigate to another page, versus those which are AJAX operations. Do NOT implement HTML, that comes later. As a team review what each dev mocks up and make sure they've thought through all of the interactions thoroughly.
From this, list what server side operations are needed in the controller for that page:
agree upon URLs
is it GET/POST
is it AJAX
whether it returns a page, partial HTML fragment, or JSON.
what parameter names for each are and data types
2) Your backend developers create controllers, exposing actions based on agreed upon design. CSHTML will for now be stubs and return nothing.
3) Your frontend developers create HTML/javascript to consume these.
They will be able to point ajax operations to the controllers, but they will need to mock what is returned since the Controllers don't know what HTML they should be returning yet.
4) Front end devs provide HTML to back end devs to incorporate into the project so that actions/partial views return the HTML or HTML fragments.
The problem is you are going to constantly be iterating through frontend devs giving HTML to backend devs to incorporate into the MVC project so that the actions that return HTML and or AJAX actions that return partial HTML fragments (PartialView) can be tested.
It makes for a very non-agile process.
You won't be able to take advantage of many frameworks for MVC which assume you are using Razor views/HTML helpers. Many frameworks for compressing/bundling javascript/less/css which integrate well with MVC are not going to be viable. You can still do this stuff, but you'll have a workflow that is not as smooth and will involve more hacking it together yourself.
I would like to point out that almost all javascript frameworks work great within CSHTML. From the client side perspective, MVC/CSHTML doesn't introduce any strangeness that prevents you from building very interactive pages. You can build a CSHTML page that is pure HTML and javascript, and makes AJAX calls to controllers, but trying to take that outside of the MVC project is going to cripple the development workflow. Designing and implementing an interactive page requires alot of consideration for how the actions on the server side are implemented.
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.
I have a CMS website written in aspx 2.0 that allows users to build up pages by dropping controls on a page and setting properties (reflection on the server side) and events (client side js). The render engine knows what property to call on each control to find out what to save into the database. I went through all the pitfalls of control re-hydration and lack of proper ids on the controls and really struggled to make the solution SEO friendly which currently is partial at best. Also suffer from viewstate getting huge so I have started to look at MVC as a better way forwards for the next version. The final design of the page is only set when the user decides to promote it live, and may make many changes per day.
A typical page may have many textbox controls, radio button groups, checkbox groups, dropdownlists and images. Also we have a few of our own controls that we reflect at runtime into the solution.
From my initial research into MVC, this looks to have been written to avoid these types of issues and not try to hide the html which looks very promising as well as giving final markup that is much more cross browser friendly.
Now the question - since the requirements are to generate dynamic pages with dynamic html controls, is this a step too far for MVC and I should stick with ASPX, or is there a way to generate the dynamic content which would be suitable for a non technical person to be able to do?
Really appreciate any guidance before I jump in with both feet :)
Thanks
Mark
I'm assuming by aspx 2.0 you mean WebForms? It's really not a question of if MVC is capable of doing what you need - it is capable, and in
my opinion it's more capable. However There are some major differences between WebForms and MVC check out this post for more on that topic: MVC versus WebForms.
I hope this helps. Without more information on exactly what you're trying to accomplish, there's not much more I can say. Consider asking more specific questions with some code examples.
Some of the main advantages of MVC: Clean HTML, No ViewState written on the page, easier to support html5 and thus SEO as well.
For me, since I used MVC 3 years ago I don't even want to touch WebForms thesedays.
Btw, if you want CMS + MVC, why not use Orchard rather than building yourself?
http://paulmason.biz/?p=118
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I am trying to teach ASP.NET MVC to students (undergrads) that have been studying ASP.NET for the last 8 weeks (I know that doesn't sound like much time, but the class is 4 hours per day, 5 days per week with Labs, Quizzes, Exams, and Wrestles).
I haven't gotten the question yet...but I know it is coming...
When would I use MVC instead of ASP??
I don't have any real experience with ASP MVC and I can't find any sort of clear-cut answer on the web. Arguments such as "...the web is stateless and ASP MVC is a closer match etc etc" do not mean much to them. They are starting to notice that ASP has lots of controls that seem to simplify their markup compared to MVC.
I'm trying to give an honest spin, and any feedback would be much appreciated!
TIA
Statelessness is a good one word to explain as already highlighted by the members.
Apart from this ask the following questions to the students?
If they have to do the following with ASP.NET (no MVC), how easy will it be?
Test your views
Mock Http objects.
Viewstate reduction (by design)(
Substitute lightweight viewengine for .aspx.
Thorough separation of concerns.
Clean HTML
etc. etc..
Now explain asp.net mvc in the above context. There may be more to it.
Atleast I think they will get the point, thought this may not be applicable to all project, but what's the harm if we are only gaining from this.
To me, the MVC approach is a very different paradigm from the ASP Forms API. I think the idea of being "stateless" is a good way to explain a very broad topic in one word actually.
One of the major advantages that I've seen is that the MVC framework gives a lot of control over the design and the output of your page. For small projects, this may not be the best use of it, but for large projects, it scales very well because you can make different architectural choices that (personally) I find to be better, such as the way that the MVC framework separates logic from the view.
Also, if you're designing a site that has a lot of Javascript, the control you gain over output in the MVC framework can be very helpful because you don't have to worry so much about how IDs and other markup may be rendered, like you typically do in the ASP Forms framework.
The MVC framework is really a totally different way to design web sites. Personally, I think it is more beneficial for large projects, but I also started out in web languages where MVC was a more popular design choice to begin with.
That's just my 2 cents.
I always thought the ASP.NET MVC Framework was a bad name since its a Design Pattern.
The question should be :
When would I use ASP.NET MVC Framework over ASP.NET Web forms?
The Developer Experience
a) ASP.NET Web Forms tries to abstract away the stateless nature of HTTP from the developer. The state of GUI Elements, and or data is stored in the Viewstate/Session. Everyone Form does a postback to itself, basically mimicking the behavior of a WinForm event driven design.
b) HTML GUI Elements are further abstracted by Controls which can be re-used, bought from 3rd party vendors. This helps developers glue an HTML app together without to much JavaScript and HTML/HTTP Knowledge. Basically similar to the way you would develop VB / WinForms
c) You can do a good job implementing the MVC/MVP pattern in ASP.NET webforms. Look at the Patterns and Practices Web Client software factory to see how they did it.
d) Developing using WebForms you are generally changing the HTML (View) based on user feedback at the server. Most events (user clicks a button, edits a field) are handled at the server in a continuous postback loop executing whats called the ASP.NET Page Lifecycle.
VS
Browser controlled view (dont know what else to call it). All changes to the HTML based on user input is handled in the browser. You will be manipulating the DOM with Javascript.
Note: I basing this on the fact that ASP.NET MVC is most likely driven by basic HTML + Ajax
How I would personally choose between them (never having used MVC, just reading on it)
1) If I was to build a pure stateless front end using Ajax, Jquery, EXT JS type libraries ASP.NET MVC would seem the better fit. Although you could build this in ASP.NET Webforms it seems pointless since you not taking advantage of the Postback model and Server Controls.
2) If I were asked to build a new basic web application, I would stick with ASP.NET Webforms since i'm already familiar with it and know the whole page lifecylce.
3) If I were asked to build a Web 2.0 (hate that term) to have a next gen User Experience, I would probably go with ASP.NET MVC, and use JQuery / ASP.NET Ajax client controls.
4) Many companies have built up a solid set of WebForm controls to use. It would be costly to rebuild them all in a pure stateless ajaxy way :)
For someone with experience (and pains) in Winforms - the biggest difference is no more Viewstate. The state of controls on the form is kept on the client, in the browser and sent to the server for each request.
If you use Javascript, it is easier to make changes on the browser side, while the server side gets an easy way to look at the form as a whole without having to recreate controls binding.
Beyond all the nice things MVC provides - separation of view/code, testability - this was for me the key point to move to MVC.
Apart from all the other excellent responses already listed. Webforms is an abstraction away from HTML.
When you want a html table of data, you put a "gridview" control on a page - what you end up with is "gridview" html, and quite possibly not exactly what you were after.
The shoe fits 90% of the time, but a lot of the time, especially when things move beyond a basic site that the controls don't fit. Using Webforms often means that you don't have full control over the final output that is rendered to the browser.
You can of course extend, or write your own grid control. But wouldn't you just prefer to write the html you want instead?
It's my experience that has the projects get more complex, and UI's get more complicated that you end up fighting webforms more and more often.
http://www.emadibrahim.com/2008/09/07/deciding-between-aspnet-mvc-and-webforms/