Is there any difference between Razor and ASPX in a MVC project?
Is it just about syntax? That's what I think after reading this... Am I wrong?
It all boils down to syntax in your webpage view, but ASPX and Razor are pretty different view engines. Razor doesn't depend on the same pipeline that ASPX does. Because of that, I'd consider Razor to be just a parsing engine.
One of the advantages of that is that you can have a Razor parser run against any string, where aspx needs an httpcontext and other heavyweight elements.
I guess it does boil down to that, yes.
As you can see from the examples in the article, the syntax is very lightweight and the interpreter is quite "smart".
You can compare it to the spark view engine and see the differences between the three.
Razor is an alternative view engine for Asp.net MVC apps, and is implemented by entirely different code than .aspx. It's like the difference between JSP and Velocity in a Java MVC web app.
razor support the test driven development.....while in the web engine having the system.web.ui
.page class does not support TDD. test driven development means testing the code in a way before you writ it.
By default, Razor Engine prevents XSS attacks(Cross-Site Scripting Attacks) means it encodes the script or html tags like <,> before rendering to view.
Razor Engine support TDD (Test Driven Development) since it is not depend on System.Web.UI.Page class.
In my opinion, I think Razor is Microsoft swinging around to scoop up all the classic ASP developers they left behind when they introduced .NET. The paradigm is very similar to ASP, server side code intermingled with client side html/js. An environment which is conducive, all over again, to the "spaghetti code" dilemma.
But for long time ASP developers, such as myself, it was the straightest route to a supported platform. And I retain the absolute control of the html/js that I am accustomed to.
Edit: BTW.... I am talking about Razor as used in .cshtml. I probably should have said that .cshtml is ms swinging around.
Related
I've just read an interesting article about how Microsoft seems to be moving towards a REST interface + client-side javascript-based MVVM development for web applications.
Although I technically understand the basic difference between the two models, I am utterly confused regarding its implications about how I write web applications and most importantly how to transition gracefully to this new model.
So, for someone moving from traditional ASP.NET MVC to WebApi + KO, the following questions arise:
Is there a way to have unobtrusive or near-unobtrusive (i.e. minimal code) validation using MVC + KO?
How does one go about unit testing his UI code?
Does browser compatibility suffer with KO?
Is there anything else someone has to consider when moving from one model to the other?
You see Microsoft starting to push this "single page web app" thing partly because it can provide a better user experience but largely because it makes it much much easier to migrate your web app to being a Windows 8 native application.
Re: unobtrusive javascript for validation… I would say that if you're using Knockout, you're UI and your scripts are going to be so tightly coupled even just for basic stuff that unobtrusiveness is really not a valid goal. You can do validation in Knockout (see https://github.com/ericmbarnard/Knockout-Validation#readme for example) but it's not unobtrusive by the same definition as ASP.NET MVC
Re: unit testing... take a look at https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit
Re: browser compat... I'm not aware of any compatibility issues with any modern browsers unless you have crazy users who have disabled JavaScript
I found this to be a really nice discussion of the pros and cons of trying to be "unobtrusive" with a Knockout site.
Traditionally I'm very much in favour of keeping Javascript as unobtrusive as possible, and with my Knockout expressions I try to keep them as minimal and tidy as possible by shifting any heavy lifting into functions on my view model and creating custom bindings which encapsulate DOM logic - but I'm firmly of the opinion that the declarative approach itself (such as the default of using the data-bind attribute), when used sensibly, is the way to go.
Perhaps it's because my introduction to Knockout is a web application "port" of a WPF application I worked on, and the Knockout bindings of my site are becoming surprisingly close to their XAML equivalents as I learn more about how to leverage Knockout gracefully. I just love being able to eyeball markup and see at a glance the real business logic around how a view is evaluated, rather than the specifics of how jQuery or whatever physically builds it in response to some click event wired up in a big soul destroying Javascript file.
When I revisit some of my traditional MVC sites which leverage lots of procedural jQuery to hook things up, I think, yeah the markup is tidy, but going back to it after 6 months even I have difficulty understanding what my intention was with all those jQuery selectors, callbacks, and DOM traversals. I think I would only apply the Knockout bindings themselves dynamically if I had to, i.e. if there was a situation where my binding logic was itself dynamic - but that could probably be accomplished differently with dynamic templates anyway.
That's my 2 cents on the unobtrusive aspect of your question, and if your experience moving to MVVM Javascript is anything like mine has been over the last few months, you won't look back.
I was once asked in an interview "What is the reason for using C# code inline in an aspx page". I couldn't answer, so I'm curious. Why would you do that instead of using code behind? Is there a technical reason?
For ASP .NET WebForms
It is not a generally recommended practice to write inline code because WebForms make heavy use of “controls” that generate HTML output and presentation logic is expected to be handled by them. For example, to iterate over a data array you would rather use asp:Repeater than foreach loop. Using a loop in this case would smell bad and remind of classic ASP days when markup and code were mixed like a spaghetti. I can only think of using Response.Write inline to output debug messages.
For ASP .NET MVC
It's a totally different situation here. Because MVC discourages using “controls” in favor of clean, hand-coded HTML markup, inline code is the preferred way of generating HTML for model views. Of course, it also depends on what exactly you are doing in the inline code. My rule of thumb is use inline code when all data needed to render the view is made readily available by the controller. Inline code should only contain presentation logic, such as showing or hiding a field based on condition, getting a string from resources, enumerating over an array in the model, etc. You should never talk with the database from the view—this is what controller is for.
Some people don't feel comfortable using inline code in ASP .NET MVC because they have learned that “inline code is bad” when programming WebForms. This is a misconception, and my answer to it is inline code is only bad when it does something other than presentation logic. In WebForms this logic is handled by controls, in MVC—by the inline code, so there is no real problem here.
I'd answer with the stereotypical "it depends"..
I would write inline C# (and frequently do) if it's a pure View concern.
It's a common pattern with MVC applications to do complex display-related stuff by using simple C# in your views..
If the code in question strictly relates to rendering the data onto the page inline C# may very well be the simplest and easiest solution (unless you use WebForms where nothing is simple). If the code is not strictly related to rendering data I'd seperate the rendering part from the processing part and only use the rendering code in the view.
I have an asp.net mvc project, its build just from views, controllers, models, and other files. I have any codebehind file in my views. Does it makes sense to create them for using sometime? Is it some situation when they giving more abilities and advantage for developer?
Thanks and take care,
Ragims
No, they make absolutely no sense in ASP.NET MVC views. By the way they are completely removed in ASP.NET MVC 2.0 views. You could make aberrations by adding one but you shouldn't.
The codebehind files are there for compatibility and for the rare case where you need logic in the View itself. Try very hard not to have any code in the codebehind, as it breaks with the very idea behind MVC to have code directly bound to a View.
#Ragims,
No matter whether Scott Hanselman might come come and kick my a$$ or not, I embed any and all code that I need in my Views, inside <% %> tags.
That being said, I try to get most processing done in a model, triggered from the controller code.
I don't think you should use codebehind, but embed what you need in the page itself.
Keep it as clean as you can, and use server side comments inside
when you can't keep it clean.
You will be better served doing stuff in a model or controller in the long run.
Codebehind vs CodeInPlace conveys no advantages that I know of.
CodeInPlace at least lets you see the code in the context of the html.
Yeah, Yeah, I know it reminds us all of the asp days. Some things in those days were pretty clear.
ymmv
I am in the process of building a large asp.net Mvc project and have a question regarding the default rendering engine opposed to the MVC Spark engine in the context for designers.
I am all in favour of reducing my tag soup and can see that the spark engine is neat, very neat and I for one would welcome it. However does anyone have an experience/opinions on whether their design team has embraced it or been opposed against it?
My designer team has yet to develop using the Mvc framework so they are either going to have to learn the default or spark engine.
Can anyone comment?
You're design team should not need to have any knowledge of the view engine at all. They should only need to know about the final product from the view engine (i.e. the HTML, CSS and Javascript that is output).
Your designers can make templates from plain old HTML and CSS, without ever seeing a single line of rendering engine code. You just have to tell them the places in the template you are going to inject the content.
The whole point of CSS/HTML templates is to provide separation between the designer and the developer. This allows these templates to be farmed-out to a design shop. You don't want the design shop to have to mess with your development code.
The designer will also be providing you with a set of text styles: h1, h2, h3, p ,etc. You will be able to plug those styles in wherever you need them in the templating code of the rendering engine to achieve the desired effects. If you wish, you can let the designer dictate some rules about the layout and use of these styles, but it's still your job to write the code that renders the output into the designer template.
So to be clear, the designer's job is to create an HTML/CSS template for you (with sample content and styling so that both of you can adequately see the layout). Your job is to incorporate the CSS/HTML the designer provides you into the view engine code.
Spark is just an HTML-ified version of C# (or VB). All other things being equal, Spark would be easier for a designer, because it changes all of the <% { %> things to HTML equivalents. But that assumes that the designers will be writing the template code for the view engine, which they won't be.
I know this question is considered 'answered', but let me answer from a 'designer' (we call it Front-end Developer) perspective.
We have a back-end (C#) team and a front-end (HTML/CSS/Javascript) team that works on .NET MVC Applications. Spark is a much more natural way to do HTML Views. Sparks adds a natural way to do ifs and loops by adding 'if' and 'each' statements as attributes of the HTML element instead of loops outside HTML tags in <% %> tags. Partials are also called from an intuitive manner. <dashboard /> will include the partial "_dashboard.spark".
Spark makes all View markup look like HTML, which I think is very important for Maintainability. It also forces good MVC habits by keeping as much logic as possible out of the View markup. The design team and create the HTML markup and the developers can then add the little bit of logic to get the content generation going.
With Spark, we have minimized the issue of ugly code and have kept front-end and back-end work separate, yet still fluid and maintainable.
I don't think designer like use Spark.
It too complicate to use and mix some logic, variable definition.
Designer should not know any programming language.
I prefer use Velocity View Engine (VTL), this is simply to use and can force programmer to separate logic from front end.
The last time I took on a non-trivial .Net/C# application I used Castle Monorail and, on the whole, enjoyed the experience. Early-access/preview releases of .Net MVC were not yet available. Many "Microsoft shops" will now find the "official" solution more appealing. Has anyone gone from Monorail to .Net MVC.
How did you find the switch?
What are the biggest differences, presently?
I have made the switch, since you pointed out it will be the preferred way for microsoft shops. The switch was pretty trivial and as Mike pointed out it ships with the webform view engine as the default, but like Mike also said you can still take advantage of the views you wrote in brail and nvelocity with the MvcContrib project. ASP.NET MVC, doesn't tie you to a direct ViewEngine, you can use any ViewEngine you want. I don't necessarily think this is a difference.
The biggest difference I found was grouping my controllers and views. In MonoRail you could do this easily with the ControllerDetails attribute, I was able to easily get around this limitation by coding my own, but wish the functionality was built in. I did it by creating my own ViewLocator and creating a ActionFilterAttribute.
I am a monorail user, so far I still feel more comfortable on MonoRail + ActiveRecord due to the convenience built at ActiveRecord ARSmartDispatchController. However have to say MonoRail does not have a good documentation base so far (I am one of those should be blamed as the community participant who didn't help enough to write the docs)
As I saw the comments here, ASP.NET MVC use WebForm view engine. I think MonoRail has that too but was being blamed to be quite problematic, so I wonder how is the experience with ASP.NET MVC WebForm- can you use the web form components mostly the way it works as is or you have to basically abandon most of them and stick to more template style approach (like <%= or <%# ?
While I haven't made the switch yet, I have developed on both platforms and have been doing some pre-switch analysis.
It looks like the biggest difference would be the View Engines. Our Monorail stuff uses the Brail view engine while asp.net mvc comes (stock) with a webforms like view engine. There are other view engines in MvcContrib which could help in this area, though.
Also ViewComponents and view "helpers" seem to be handled quite differently the two frameworks.
Lucky I am not working for an organization use product ship from Microsoft is a needed. So I might not directly answer to your question, However in term of using MonoRail I enjoy every part of the framework although the lack of documentation but test suite are there to guide me through.
In short I do not want to invested time in learning new framework although it closely match (each had it own convention) but ASP.NET MVC still lack of some features that I already familiar with such as feature mention by Dale Ragon ControllerDetail, ActiveRecord and so on.
The ASP.NET MVC team is still making changes before v1.0, so now's a good time to provide feedback.
Also, be aware that there are more frequent releases on CodePlex, while the home page on www.asp.net still links to Preview 3.