I have been looking at ASP.Net Web Pages and I think it would be a good replacement for some classic asp sites I am working on. There is a lot about them that is similar to how classic asp did things, so I believe there is a chance I can drag the other programmers into the present. My problem is that I have yet been able to find any indepth documentation to see if there is any "gotchas" I need to be aware of if I choose to go down this path. So if anyone knows of any, I could really use that information. I think going straight to MVC and Web Forms would be a bridge too far for the others at the moment. Thanks.
Wade
I found a link from Mike Brind - should I use WebMatrix to build a real-world website?
I'd suggest that Web Pages as a framework is probably the best next step you can take, but I would also advise that at least one person in the team takes time to understand the basics behind the MVC pattern. You may decide it's too much for the majority of the team at the moment, and that's fair enough, but you can use your knowledge to plan the development of the Web Pages site so that it can be more easily converted to MVC at some stage in the future, should you decide that's the way to go.
The things I would look at (coming from a classic ASP background myself) are functions and helpers. Decide on a data access strategy - The Entity Framework works well with Web Pages and can be transferred to MVC easily. Avoid the Database helper. Use Visual Web Developer 2010 SP1 for the Intellisense option.
As Knox said, you have the whole of the ASP.NET framework available to you so there should be no Web Pages specific "gotchas", and it's a massive step up from classic ASP.
I've been using Webmatrix/WebPages/Razor for a while now and like it. It's been a while since I used Classic ASP, but WebPages to me feels like a true successor to classic asp and what ASP.net should have been from the start. I'm actually moving most of my smaller sites to the WebPages framework from WebForms. Here are some things I've encountered.
I'm not sure if this is a gotcha or not, but I thought I would mention that with WebPages the scope of your variables may behave differently. I know a lot of Classic ASP sites that used to use include files to run snippets of code. Many of them depended on global variables set in the parent document. In WebPages, if you use RenderPage or Helpers to replace includes they run mostly outside of the Parent's scope. If you used Server.Execute instead of includes then you might not notice much difference, but if you did use includes and lots of global variables you may notice it.
Another possible gotcha is in ClassicASP <%=%> doesn't encode output, but in WebPages the Razor syntax # encodes output by default.
Another thing to consider is using C# vs VB.net with Webpages. Although vb.net works you'll find that most samples, tutorials and people in forums use C#.
Finally something that bothers me is that it is named the "webpages" framework. I've found it hard to do a good Google search using the term "webpages". Even "asp.net webpages" brings back mostly webform results. I have more success using "webmatrix" or "razor".
Can't recommend any documentation but here is an introduction to Web Matrix on mikesdotnetting.com blog where he has blogged quite a lot about Web Pages with Web Matrix.
We have two production sites, developed using Web Matrix. One serves our customers, the other is an intranet for our staff. They've been running in production for almost a year. I'd say about 95% of the sites were developed purely in WebMatrix IDE with about 5% going into Visual Studio, especially for the occassional obscure debugging. We're happy with WebMatrix / Web Pages. I didn't use WebForms because I was concerned about WebForm's ability to do really lightweight pages, since many of our users are using cellular data on iPads or iPhones. I didn't use MVC because of the additional complexity, since many of our pages are just showing the user read-only data from our production database. Because WebMatrix gives you access to the complete ASP.NET library, I haven't felt held back at all.
We are currently converting our ASP pages to Web Matrix. We tried to do conversions using WebForms a few years ago, only ending in frustration. After a small learning curve on the C# and Razor syntax, our development staff feel that we made a correct decision in going with Web Matrix.
i know ASP.NET and i would like to learn and make a new project in ASP.NET MVC.
Is it easy to move from asp.net to asp.net mvc? Will the knowledge i have so far be helpful?
Im asking because i will have only few days to learn asp.net mvc and i want to know whether it's possible...
Cheers
I think you will find this questions (and its answers) very helpful.
Is it easy to move from asp.net to
asp.net mvc?
My answer to this would be a question back to you. Do you understand HTTP? Is web forms sort of magical to you, or do you have a firm grasp of what the abstraction is doing?
The reason I ask is that MVC sort of strips away a lot of the "magic" that web forms gives you in terms of treating a stateless protocol as actually having state. I tend to think of out of the box web forms development closer to classic windows forms development then normal web development. There are good and bad things about that.
What MVC is doing is bringing closer to what is actually happening in HTTP and in the end giving you more control and power over that. What you won't find in MVC is slew of drag and drop datagrid type controls, but it will make it easier to write AJAX heavy sites with common javascript libraries and clean html, as well as enable you to more easily write testable code.
Will the knowledge i have so far be helpful?
Without knowing what your "knowledge" is, it is hard to say. Obviously c# and vb are the same it's not like its a new language.
It really comes down to what type of web developer you were in asp.net forms. If you found yourself annoyed at how IDs were generated and how the html output of controls was horrible and that the framework was making it hard to do what you want then you should be fine.
If you were like I stated before, more of a drag and drop type of web forms person than MVC might be a bit challenging, but I would say its a good challenge and something that will ultimately make you a better web developer.
The only way you'll really know is if you try... There are tons of resources out there to get you started.
Hope that helps. Don't be afraid to ask questions on here as you go, there are tons of MVC devs on this site.
If you've ever used technologies like ASP classic, Coldfusion, PHP, etc. where you intersperse regular markup with server-side logic, then you will be able to pick up the "view" syntax pretty easily. The controllers are pretty simple to grasp once you get the hang of it, and the model shouldn't have to change from what you are used to. The hardest part for me to grasp when first learning ASP.NET MVC was the routing.
Like anything else, it will take some effort before you learn the "right" ways to do certain things, and you will initially be a bit less productive in the new technology. But in the end it is worth it.
Personally, I felt that ASP.NET MVC was far easier to learn than ASP.NET WebForms.
Run through the NerdDinner tutorial. It should take you about half-a-day. I think you'll find the simplicity refreshing.
One of the common questions asked regarding ASP.NET MVC is why should you use it over ASP.NET Web Forms? The answer generally includes ViewState and clean URLs, amongst others. Towards the end you'll find a blurb about using the right tool for the job and that they serve different purposes. However, I don't believe I've ever seen what those purposes are. So, when would you actually choose ASP.NET MVC over ASP.NET Web Forms, or ASP.NET Web Forms over ASP.NET MVC?
You don't choose ASP.Net MVC over ASP.Net, because ASP.Net MVC still is ASP.Net. You do choose ASP.Net MVC or ASP.Net Web Forms, and there are lots of good reasons to do that:
Easier to get control over your HTML
Easier to do unit testing
Few "Gotchas"
On the other hand, Web Forms do have a few points in their favor:
Easy to put simple CRUD/business apps together extremely fast
Hard to beat ViewState performance in local LAN environment
Easy to learn forms paradigm
The result is that if you're building business apps in a corporate LAN environment (which honestly is still most web developers), Web Forms is really great. In that sense Microsoft really knows their market. But if you're building an app for the public internet, you might want MVC so you can test thoroughly and be sure your pages aren't bloated with unnecessary ViewState or JavaScript data.
Additionally, something that has changed over the last several years is that even many corporate intranet applications now need to support home/remote use, making MVC more attractive to that crowd than it had been.
Use MVC if all your team members are skilled enough to manage "control over HTML", otherwise your code will turn into a tag soup.
In other words
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
check that blog !
Bottom line "separation of concerns"
I'll give you a couple purposes, with clear advantages.
If your purpose is a public facing website that will be banking on traffic, use MVC. It is optimal for search engine optimization.
If your purpose is an enterprise web-application that acts like a desktop app, I would lean towards web forms, since state management and compartmentalization of your resources into underlying server controls offers huge advantages if used correctly.
The biggest problems facing developers is managing complexity and keeping code "clean". MVC gives the developer the reins to leverage OOP to tuck away complexity and make code easy on the eyes.
Webforms will be faster to develop in the short term, but it doesn't lend itself to long term sustainability in terms of maintenance and growth.
I've worked with Web forms for 13 years and MVC for 2 years now and when I started with MVC, I had similar questions. Here are my takeaways.
Most importantly: ASP.NET's latest release is 4.6 and they were moving to ASP.NET 5.0, but MS abandoned that for ASP.NET Core, which no longer supports Web Forms (or even VB.NET). So, that alone might give you your answer when deciding what rabbit hole to go down.
That being said:
MVC I'm finding, once you get the hang of it, is WAY easier for dealing with basic forms and any sort of simple "Model", aka tables with a very simple, straight-forward set of relationships such as orders that have tables that link to users, products, etc. Once you start getting into some more complicated relationships and need to return lots of conditional sets of results, rely on parameters, have complicated stored procedures... then Web Forms is much better for dealing with this. If you don't have to deal with this level of complication, MVC makes development SO MUCH faster, especially with dealing with an approach where you already have the DB because it creates so much of the code and validation for you already
If you're not very experienced with database design, MVC does the work for you. It can literally build the database for you.
MVC doesn't have a lot of the built in controls that Web Forms does (Gridviews, FormViews, Sitemaps, Paged lists). Everything has to be written from scratch, but luckily a lot of people have already invented that stuff for you in NuGet which you can just download into your project
MVC relies heavily on the structure of your URL. The path, the querystring, etc. If you find your application needing to do a lot of form POSTing instead of GET-ting, you're going to have to do a lot of tweaking or AJAX posting. If you have a set URL that can't change, it can be a pain. It's doable, but just a little tricker (or you can just use Angular instead).
MVC has no Viewstate. If you need to hide variables from post to post and persist them, it's a little difficult. MVC Does have things like ViewBag which lets you pass data from your controller to your page, but it clears after the page is rendered. There is also something called "Tempdata" which acts like Session state, but more temporary. However, it relies on Session State which is not an ideal way of persisting data. Session variables and tempdata variables are fine for user-level data (profile information for the person logged in), but having two different tabs open by the same user can cause these session/tempdata variables to overwrite each other when you're dealing with the actual model data.
If you're at a crossroads, I'd go with MVC. MS is pushing it and support for Web Forms will likely start going away
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Having worked with Classic ASP for about 2 years now by creating a few 100 simple web forms I can't see a good reason for switching to .net; however, I'm not that versed in .net so I'm sure I could be missing a few things.
Some points that I often hear around work can be found here: http://www.packtpub.com/article/Classic-ASP (not that I share all of these thoughts, but it's a good jumping off point)
I'm very interested to hear what others have to say on this matter.
You're missing more than a few things! ASP.NET is orders of magnitudes more productive, robust, and maintainable than old-school ASP ever thought about being. Server side controls, third-party controls, master pages, forms authentication, forms validation, an OO model than encourages appropriate application partitioning, easy deployment, built-in debugging and tracing, state management.
You even have the choice of WebForms or MVC. It's not an understatement to say that you are simply out of your mind if you don't thoroughly investigate what you're missing.
If you like ASP, and want to move to ASP.NET, skip Webforms and learn MVC.
The biggest issue for me is that I create applications, not websites...The UI is a minor part of the problem, the big part is writing the business logic layer, and various enterprise communication components (Connecting to SAP using SOAP? No Problem!).
The .NET Toolkit allows me to program in a wonderful object oriented language (C#) and has a robust framework to help out.
VbScript is a godawful language to try and write a business application in.
However, if all you do is a simple little webform, then sure, use VbScript.
As far as your link, it basically boils down:
WaaWaa, I don't like Visual Studio
WaaWaa, I want to edit production code on the production server like an idiot.
WaaWaa, I don't know that deploying a single compiled DLL is all that a small site needs to deploy a asp.net app.
Basicly, its ignorance in a nutshell.
To focus on the specific question ("benefits of Classic vs .Net"), there are only two things I can think of Classic does that .Net won't:
1) Includes. They just don't work like you expect in ASP.Net. Of course, ASP.Net provides much better ways of accomplishing the same thing, but it's still a bit of a loss and can make migrating an old site to .Net a pain.
2) ASP.Net won't go above the root folder for the application. Where I'm at we have a rather complex intranet that's still mostly classic ASP, with a smattering of .Net apps here and there as things are updated or new stuff added. It would be nice to be able to keep one copy of common code up fairly high in the folder hierarchy but still have each individual app isolated to it's own VD. But then, that's what source control is for, so it's not a big deal.
For me, the biggest advantage moving from Classic ASP and ASP.Net so far is the IDE. It's so nice to be able to right click on a function call and choose "Go to Definition" rather than having to dig around to find the file where the function is actually implemented. Huge time-saver. And intellisense support and type safety when calling functions is a boon as well.
For me I'd have to say Classic ASP is quick to develop in, simple to use/pick up, not overly complicated and very capable of most things asked of it.
ASP with JScript/Javascript as the main language is really, really good fun to code with. VBScript is a waste of brain power and I think its that which gives Classic ASP its bad name. Plus its considered slow but all the articles about speed and number of users are based on 10+ year old servers. We run a site getting 60,000 users a day on two servers and the CPU barely flickers. Modern servers give you a lot more power to play with.
With the huge leaps forward in Javascript usage, designs and best practises in recent years the ASP JScript coder can get alot of goodies to make life even easier. I've ported Mootools to server-side and with that we get an load of wonderful helps, class model, excellent event model and so much more. ASP is great fun. UPDATE: Mootools now have a server-side build that you can download (http://mootools.net/download).
ASP.net is SUPER powerful but has a big ramp on the learning curve to do well, can bring your whole site down when it has one of its fits and worst for me can seem to really go around the houses to get the most simplest of things done.
I'm having alot of fun using both at the minute, using which ever one best fits the gap. I've a great little CMS Cacher and Thumbnailer build in .net which my ASP scripts use. Best of both worlds.
Performance, scalability, and a framework that provides a much better foundation for the stateless world of web applications, for a start.
Wikipedia's ASP.Net page has a section on the differences.
If you look back at your old code and say, "What was I thinking! This is rubbish, I write code much better now!" then you have developed as a programmer.
If the sites are fairly temporary (i.e. you build it quickly, it gets used for a specific purpose and amount of time and then it is effectively closed) then banging out these sites in the most comfortable way for you is perfectly acceptable.
If you have a long list of bugs, fixes and improvements that you now need (or would like) to backport to your old sites, or your "small sites" are getting bigger and more complidated and this is causing you significant grief then you need to take a step back and re-evaluate how you structure and support these sites.
I would very much agree that ASP.NET is a very much more mature and effective programming environment. However, like any tool, you need to know (or learn) the right way to use it as it's not going to automatically turn you into a "super programmer" overnight.
A way to break the ice is to agree with your boss that the next "site" you create is developed in ASP.NET. Explain to him that it will take quite a lot longer than how you currently deliver sites because you have to "get your head around" ASP.NET, but the benefits are x,y and (exercise left to the reader!)
Personally, I'm still in the transition phase (and I started using ASP.NET from v1!) as I have a fairly robust Classic ASP framework I'm developed and comfortable with. However, I have used ASP.NET strategically and have found it VERY powerful and your do end up writing must less code, as so much is built into the .net framework, as long as you can find it in documentation.
I also recommend that you DONT use VB.NET and your bite the bullet to use C#. The change of language is quite minor, but you reduce the chances of writing your sites exactly the same was as you used to. It helps break the bad habits annd gives you a chance to learn new techniques.
Good Luck!
For simple sites, I actually prefer ASP vs. ASP.NET, especially if you know HTML well. However with ASP, separating business logic from view is hard; the code you write will likely be challenging to read + maintain.
PHP is better than ASP though - and somewhat similar at the basic level. And you could always go to Rails or Django, if you're interested in self-contained web development stack (but a lot longer learning curve).
I have one word "debugging" - you never want to have to use it but you always do. In .Net if you're using Visual Studio you have a fantastic debugger when compared to trying to debug code on ASP.
Rarely does a response in this thread answer the question. Instead of taking the easy way out, I'll take a stab at it:
A few benefits that have not been mentioned (JScript-centric):
You can learn the entire language and keep it in your memory if you use it enough - I don't know anyone who claims to know the entire .NET framework; this makes coding very rapid.
Weak typing - this can let you code more rapidly when banging something out quickly, e.g., do you really care about the difference between char and string most of the time? (insert religious flame-war here)
Eval: this much-maligned keyword is actually incredibly powerful, and lets you manipulate your code at runtime in really interesting ways
Client/server language compatibility: JScript's similarity to Javascript means that you can use the same include file for server-side validation as you use for client-side.
One advantage to ASP.NET is that you have the option of coding your site exactly as you did with classic ASP, along with access to the richness of the .NET framework. You can keep existing functionality and add new ASP.NET functionality were needed. They mix well.
Unfortunately the author of the referenced article isn't very well versed in the technology behind ASP.NET as evident by his remarks (and maybe not even classic ASP). Most of his points are invalid or simply wrong.
Everyone here has made valid points.
I was a classic ASP developer until 3 yrs ago when I switched to .NET 2.0.
I couldn't go back (even though I do still have to fix a handful of classic ASP sites).
I do miss having a recordset object, data repeaters are great for displaying data quickly, but datasets, whilst offering wonderful functionality, are dame awful when it comes to performance on 'big' sites. In fairness I've been doing datasets in a roundabout way with Arrays in classic ASP. The only time I use datasets is for my e-commerce site baskets. I do miss rs.movenext, etc...
FlySwat has made one of the biggest mistakes that I see a lot of developers make.
Yes business logic, OO etc... that .NET brings is great (scalability I wouldn’t 100% agree with, but definitely more extensible), but when using ASP.NET you are still creating a WEB SITE. Forget this nonsense of using the terminology ‘application’. I have meet many great .NET developers who build n-tier, OO sites, but they have no real understanding of the uniqueness of building a web site; such as state, or the bloody annoying problem that they over rely on Javascript. Most of these developers build MS type sites which don't normally meet W3C, aren’t cross browser friendly and never gracefully degrade. And no it is not acceptable even for back office applications to be only compatible with IE.
.NET also tends to 'fatten' simple sites. .NET in many ways was a way of getting WinForm developers to start building web sites (or as they prefer, web apps.). The problem was that this brought with it a bunch of developers who had the luxuries not having to worry about state, standards, etc...
I still maintain that any .NET site can be built in classic ASP and run faster (page response times) for the end user....
...BUT though I have fond memories of classic ASP, what I can do with .NET in terms of imaging, encryption, compression, easy web service integration, proper OO, decent n-tier, extensibility, etc...is what gives .NET the advantage. Even silly things like simply adding one line of code to the web.config to tell it to write the sessionID to the querystring if the user doesn’t accept cookies (this was a pain in classic ASP) is great.
Move to .NET, you won’t regret it, but do give yourself sometime (particularly if you don’t know about OO (inheritance, abstraction, polymorphism and encapsulation). Don’t start building .NET sites in classic compatibility mode, it’s just a cheap way of doing .NET and you’ll still end up using classic ASP practises. If VBScript was your main development language, the jump is no were near as easy as MS or others would have you believe.
Most importantly for me is that I have carried across, from my classic ASP days, fundamental web site application (;-)) design and this should never change between languages.
If all you make is simple little web pages, then do whatever. Or better yet learn PHP. Most of the response you are going to get are from people who make web applications, and for that asp.net blows the pants off of classic asp in power and maintainability though.
I agree with everyone here except the one who said skip webforms and go straight to MVC. This is not helpful. Webforms is very useful for database-driven applications which do lots of table displays, etc. I have worked on some very large webforms applications and it works fine. MVC is good for more interactive "Web 2.0" type applications.
I always use Classic ASP, it works beautifully.
I tried ASP.net for a couple of years but it was too complex for most website development. My customers didn't like it either because they couldn't understand it. They also like knowing they are not locked into one developer.
ASP.NET keeps changing and requires enormous/constant learning curve to keep current. MS switched primary language to C# which made the transition just that much harder.
My productivity slowed to a crawl with .net because I was forever out looking for tutorials or examples of how to do everything.
Visual Studio is pig sloooooow.
PHP has an ugly syntax and too many different frameworks which makes it impossible to learn for developer purposes. Good only for intranet use with dedicated staff, in my opinion.
Classic ASP is locked down and works perfectly today just as it did years ago. With a few library files, code writing is easy as pie and examples are unlimited on the internet.
Written correctly, which most folks don't, vbscript is clean readable, efficient code. I leave the client side stuff for libraries like jQuery and find I am many times more productive.
Having done a "rename asp to aspx and change until it compiles" port of an application to asp.net I would say that even asp classic style programming in .NET is better than asp classic. VS of course will encourage you to fall into the pit of success and drive you towards the web forms and code-behind way of doing things, but the language is expressive enough to replicate the patterns of asp classic (namely lots of golden nuggets/inline code, cross posting pages, etc)
I think I've heard it said before that you can write COBOL in any language. That's true for classic asp.
5 Reasons You Should Take a Closer Look at ASP.NET MVC
If you use classic asp at this point (without a mandate from your CTO) then you need to see a shrink. or you are a masochist. Or as satanist, in which case, you'd like it cuz you'd be in hell! :p
On a serious note... for web applications use WebForms.
For light, quick and dirty websites, use ASP.NET MVC.
Good thing about ASP is that you can use VB.NET, C#, Eiffel, Boo or PHP for your language! For PHP check out Phalanger...
Since I'm paid to create solutions and not to write code, I just prefer ASP.NET over classic ASP. While classic ASP is still practical for very small, simple sites, there's still a lot of power behind ASP.NET when writing a bit more complex sites. Besides, even with ASP.NET you could still just use Notepad to write the .aspx files yourself, including embedded vb or c# code. Visual Studio just provides a lot of additional functionality that takes away the need to write more code yourself.
And, as I said, I don't get paid for writing code...