What kind of framework is Razor? Is it backend or frontend?
What is the difference between the two types of frameworks?
I'm trying to learn a little bit more about backend and frontend frameworks and since I usually work with Visual Studio Asp.net MVC was wondering about it.
It is not a framework . I think you're misinterpreting certain concepts. Razor is a server side view engine, and it uses C # or VB.NET to generate dynamic content.
Razor Syntax Quick Reference
This question is a couple of years old, but I'm going to add my two cents.
People struggle to give an answer to this question because the terms 'front-end' and 'back-end' aren't formally defined anywhere. Because of that, any answer is purely subjective.
That being said, it is my opinion that the relationship between front-end/back-end and client-side/server-side isn't necessarily one-to-one
I think it helps to think of it like this: client-side and server-side are run-times, while front-end and back-end are a separation of concerns.
'Client-side' always refers to code executing on the client's machine and 'server-side' always refers to code executing on the server. A 'front-end' developer deals with displaying data to the user and getting data from the user, while a back-end developer deals with storing, manipulating, and retrieving that data.
Consider a front-end developer who is tasked with building a UI. Much of the code they write will be the typical HTML / CSS / JS. However, they will also have to deal with the data that is passed to the front-end from the backend. This is where Razor comes into play. The front-end developer will write the Razor code (which executes on the server-side) to display the data.
That is, the front-end developer will write server-side code to help generate the UI, in addition to writing the client-side code that really defines the UI.
Now, I can't imagine a scenario where a back-end developer will write client-side code.
So, to answer your question, Razor is a front-end technology that executes on the server-side runtime. It's only purpose is to generate the UI, which is the concern of the front-end.
Razor is for writing dynamic html page which is front end and c# is for writing backend logic. Although you could move all the backend logic inside razor but its highly not recommended.
Razor allows you on the back-end more easily create views (.cshtml in C#).
It is more like templating system...
http://www.asp.net/web-pages/overview/getting-started/introducing-razor-syntax-c
Related
With the latest release of ASP.NET CORE version 2.0 we now have Razor Pages which I really like because it shows a MVVM way of developing which I am already familiar because I've used it in UWP.
I was searching to develop web apps without js because I am a .net developer and I came across this framework known as DOTVVM , it is great because it gives some features of js frameworks like Angular, React etc. and it also integrates very well with ASP.NET CORE 2.0
I want to discuss this between following 3 scenarios :
I should use DOTVVM and not use JS at all.
I should use Razor pages instead with asp.net core 2.0, because razor pages provide all functionality which dotvvm provides and it will have more community in future.
I should learn a JS framework like Angular or React because neither razor pages, nor dotvvm is powerful enough to replace them.
The discussion can be from point of view of all developers, so I can get opinion of JS developers as well as those who have worked with dotvvm or Razor pages. The aim is to create completely interactive and responsive web app with good performance.
**Important : ** the web app created can be a progressive web app from the start or maybe turned into a pwa after creating it, depends on the technology I choose at the end.
I know for a progressive web app I will need to write a little JS, but that is alright considering that is very simple and little to write.
The reason of this question is so that we can discuss these options from multiple perspectives and deduce a better option at the end for my app.
It really depends on the type of the application you are trying to create. The fact is that you can build any application in any web technology. The difference is only in how difficult it would be.
Razor Pages are very easy to use and they are part of ASP.NET Core platform. They are using the MVVM pattern, but they are not helping with client interactivity. If you need to hide some form field based on some condition, you would need to do it in JavaScript.
I would use them for a simple company website, very simple admin sites with few pages and trivial forms, or for a public facing part of some eCommerce site. I would probably use also jQuery or other libraries to do the interactivity, animations and things like that.
DotVVM is an MVVM framework which helps especially with web applications with complicated UI: lots of complex forms with dozens of fields and interactivity (when you select an item in a combobox, another combobox will get new values, some fields will be pre-filled, a part of the form will disappear or change and so on). Modal dialogs, multi-step wizards, lots of grids with data, sorting, paging...
Because DotVVM handles many things for you and translates the data-bindings to JavaScript, you don't need to write the JS yourself. It doesn't mean that you should not learn it. It will help you a lot if you know it - you will be able to add even more interactivity, extend the framework when you need it and more. DotVVM lets you do quite a lot without knowing JS, but you will get much further if you know it.
Angular, React or other client-side frameworks are used widely today and many websites and applications are built in that. They are more universal than DotVVM, which aims primarily at the business app segment and requires .NET on the server (because it is not only the client-side library).
Using Angular or React requires the knowledge of JavaScript, and not only that. You will need to know Node.js and the related tooling, like npm. You will need to exchange data with the server, so you will need to build probably a REST API, use Swagger to generate the client-side proxy classes, and then you will probably need some other JS libraries with controls and things like that.
It is quite a lot of things to learn and if you are used to the comfort of Visual Studio, like the IntelliSense or the debugger, you will miss these features for sure.
And finally, you don't need to stick to one technology. You can combine Razor Pages with DotVVM for example. You can make the admin dashboard in DotVVM and the public part of the website in Razor Pages.
Microsoft is coming back to the WebForms approach to simplify the project structure trusting in the "Convention over configuration" mantra, while hiding the configuration from developer to make things faster. But it has the disavantage that everything will be mixed again. I doesn't look like a smart move for organizing. But... Hey! Something new must catch the attention of the dev towards Microsoft.
If your page uses an MVC Web API for the REStful, it's really more easy to just use Razor pages. If not, I would recommend you to use Core MVC.
I'm bringing myself up to speed on Javascript, and I'm beginning to wonder if there is a purpose to using a Javascript framework like Backbone/Knockout if I'm already using ASP.Net MVC on the server side.
Since I'm trying to create a single-page browser experience, I can see why having a Javascript framework would be useful in general, but I'm beginning to wonder if I can't create a better experience just relying on AJAX server connections to update the page portions I want refreshed. I guess in general: what is the purpose of a Javascript framework?
While there are plenty of advocates for using Backbone and Knockout with MVC (Scott Guthrie was one of them with his SPA sample project), I find it overkill for a lot of my projects.
Lately I've been quite addicted to managing my JavaScript dependencies with Require.Js. It speeds up loading, helps me to modularize my code, and provides some handy uglification. However, at the end of the day, it is up to you to decide how much client-side architectural overhead you need.
As an aside, you may want to consider AngularJS as an alternative to Backbone/Knockout.
First off, I would say that nowadays most users expect dynamic experiences as well as responsive interfaces (responsive in terms of speed not the buzzword responsive). To achieve this, using JavaScript is generally the way to go. Usually you save yourself round trips to the server, which take up time and bandwidth.
As far as using a JavaScript framework, and choosing which one to use, that is really going to depend on the type of application you plan on building. For example, Backbone is great at structuring your application, whilst Knockout is great at handing user interaction. There is a bunch more variables that go in to this though, and there are plenty of blog posts which compare and contrast the various frameworks.
You will be hard pressed to get a truly interactive and dynamic web application without using JavaScript these days. The various frameworks will hopefully help you achieve the features you would like.
Javascript frameworks make SPA's and rich client side interactivity smoother, at the cost of more implementation than server side alone. The workhorse of Knockout is it's ability to update the DOM real time when models change, so you don't have to navigate and modify the DOM yourself. Its a tool. If you need it for your project, then by all means give it a shot, its probably worth the learning curve and learning javascript the object oriented way. If not, then you are wasting valuable slacker time by creating client and server side models.
How time consuming is it to move a website built using Webforms to one built using MVC?
I have an existing website built using asp.net webforms, but it is a little annoying. I want to use lots of javascript and ajax, but webforms makes this a little difficult. It tries to do too much for me, and thus makes it difficult to work with when I want to do things it doesn't expect.
As such, I've taken to only using the Page_Load event, and totally ignoring all the postback stuff - when I need to deal with submitting forms, I handle it manually from the Page_Load event with Request.Form["ElementName"], but most of the time I use javascript.
I've heard that asp.net MVC is much nicer to work with, so I'm thinking of porting my site over to this. Given that I am writing runat="server" only on standard HTML elements that I need to fill with data with .innerHTML =, how long will it take me to move over to MVC? Or is it a totally stupid idea to attempt this move?
well, as you've probably guessed, it's such a broad ranging question that it would be almost impossible to give advice on your individual scenario without seeing the scale of the existing codebase. However, there are many mitigating factors that you may want to think of regarding moving functionality across piecemeal, such as:
can I break down the existing functionality into discreet segments
does the exisiting site still require all current features
are there new features that I could introduce purely in mvc
do i need to extend the object model - EF code-first may give huge advantage via mvcscaffolding
the beauty with asp.net is that you can mix-match webforms and mvc together, thus you can chip away at functionality as required. Of course, there are so many resources on mvc on the web now, it'll be easy to get going quickly, so i'm sure you'll make good progress.
I think you'll really enjoy mvc - it's a no going back experience.
[edit] - there are a few interesting resources on the web that discuss the mix of webforms and mvc. however, the definitive one for me has to be scott hanselmans from a wee while back. still relevent in mvc3 as it was then:
http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
also:
http://www.aspnetmvcninja.com/general/mixing-asp-net-mvc-and-webforms
Short answer, impossible to tell here.
Long answer, it depends...
It depends on how many sites you have to rewrite, complexity of the site and your architecture.
If all your logic is in the code behind files you will have a long walk.
If your architecture separates responsibility with use of services and abstraction, a lot easier.
If I should walk that walk, I would look into porting the code bit by bit. I've done this with JSF and Spring MVC, and it looks like this is doable with .Net too.
http://weblogs.asp.net/rajbk/archive/2010/05/11/running-asp-net-webforms-and-asp-net-mvc-side-by-side.aspx
Wanting to improve your code and your skills is never a stupid move!
It is possible to use them both within the same application. It isn't necessarily advisable, but if you set an MVC project up, you can tell it to ignore page requests that map to your webform pages.
You can then start moving over functionality as you need it.
If there is likely to be functionality you need to be available across MVC and webform pages, then this is going to get complicated and you are probably best moving to MVC in one go.
Personally, what ever you do, start small and straightforward and if you can bit by bit.
It would have to be a rewrite, not a port. MVC sites are built very differently from WebForms sites.
MVC is not based on the ASP.NET request lifecycle. There is no codebehind; business logic gets called from Controller classes; data is encapsulated in Models which are then passed to Views. It's a totally different beast from ASP.NET.
And be warned: once you've made the switch to MVC, you'll never go back to the old world of ASP.NET! :-)
Good luck!
I wanted to give a try to razor but there are not many tutorials on web; I've already tried this one, so better ask here. Can anyone please tell me how razor works? I mean are there any code behind pages or controls? and what is done in code behind pages if they exist? Also, how can I reference code behind pages? Generally speaking, what type of code fits in the cshtml page, I mean, for the sake of a clear design how should be the structure etc etc. finally, any good tutorial is highly appreciated. Thanks!
Please note: I'm not using visual studio, I'm using webmatrix.
I can't speak a whole lot to WebMatrix. But...are you familiar with ASP.NET MVC? Given what you're asking, it sounds like maybe you aren't. I would start with learning the basics of MVC first. I learned on the NerdDinner example
http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx
To answer your question more directly, no there are no code behind files (though a code behind is technically possibly through some hackery). The paradigm is completely different from web forms. Essentially you have classes called controllers that accumulate the data for a page. The "data" for the page is referred to as a model and closely resembles what your problem domain is. Models are classes intended to represent objects in the system (customers, users, orders, widgets, etc...). The controller passes models to the view. The view renders the page. So the code you'd expect to find in each of these is:
Model: object representing the problem domain like Blog, Person, User, etc...
Controller: Gets data from database using services that return Model objects (or calls into entity framework, NHibernate, whatever)
View: displays that using cshtml, aspx or whatever the ViewRenderer is
So, in your view (cshtml), you're really just going to have straightforward programming for displaying UI elements and performing UI logic. You'll have mostly HTML and then some bits scattered around to pull data from the model and display it like
<td>#Model.Name</td>
<td>#Model.Description</td>
Hope that helps
EDIT: After reading a bit more, sounds like WebMatrix is kind of a RAD tool for web apps. Looking at the tutorial that you posted, looks like they're showing you go treat it like classic ASP and put everything right on the cshtml page. This is an option. I wouldn't recommend it though. It'll make life tough, but I'm unsure if there are better ways in WebMatrix.
Razor is a view engine, which can be used by itself in Razor pages (.CSHTML/.VBHTML) or in ASP.NET MVC. If you use it by itself, it's kind of like writing classic ASP or PHP, where the code is all inline. No code-behinds. Here's a brief introduction to the syntax:
http://www.mikesdotnetting.com/Article/153/Inline-Razor-Syntax-Overview
That site also has a lot of other great articles about the nature of Razor.
create App_Code folder put cs file to this folder
convert App_Code to dll in bin folder then upload bin folder
(by visual studio 2012/publish web site)
I am developing a Flex / Flash application which talks to an ASP.Net / C# backend. Is there any way I can share code between the two?
The server provides a reasonably interesting domain model which the client is designed to maniuplate. Ideally I would like to be able to define this domain model once and have both sides use it for consistency. I am after all the benefits that come with being DRY.
I'm new to Flex but the sort of thing I had in mind was some intermediate language that compile to both C# and ActionScript.
Update
I currently have a basic REST style web service which sends XML serialized versions of the objects down the wire to Flex. This works fine but what I am really interested in is being able to share simple business logic that goes along with these objects. There are certain business rules that need to be processed on both the server and the client and is possible I would prefer not to have to call back to the server for performance reasons.
I faced this problem as well, so I wrote a C# to ActionScript converter.
http://cs2as.codeplex.com/
Write your logic in C#, and add this utility as a post-build step. Then your business logic will be available in both environments. It works very well for me - I'm using it to share over 30,000 lines of code.
I'd hack together a domain model specification and have it generate models in both languages. But that's probably not the most time-effective thing to do.
Check out http://www.fluorinefx.com/ (It is open source flash remoting). I have used it extensively to call web services written in C# from ActionScript, and it works great. Once nice thing is that your c# can return a DataSet (or something similar) and the Flourine framework will convert that into an object ActionScript understands.
Not that I'm aware of, C# is essentially a strongly-typed, compiled language and ActionScript is a loosely-typed, interpreted language. Chalk and cheese I'm afraid.
What if you serialize the objects to XML and send them to Flex....that would at least let you share the data
Update
You can pass objects through the use of Lists, but what you're really passing through is just the data.
You can't really pass a 'method' to a client.
They don't necessarily have to honor it. Once they're in possession of the data, you can't control whether they honor the methods you passed or not.
You wouldn't want to trust anything they send back to you subsequently.
I think the issue is with the set-up.
You can process anything you want on the client side using ActionScript, and you'll just have to put the business logic you want to manipulate in the ActionScript side of things if you want to do it on the client-side.
Olde Answer
I use Flex and C# together through the use of a web service layer.
You may want to look at creating web services to have flex talk to your C# code.
Web Services with ASP.NET
CodePlex ASP.NET Tutorial (web services)
try weborb # http://www.themidnightcoders.com/products/weborb-for-net/overview.html