I'm sorry if this is a stupid or obvious question, but I've spent the better part of a week researching, and I really can't find any resources that explain what MVC 4 and Razor are, and what they are intended to do in web development. I'm not necessarily asking for a really detailed description, even a link to a website or the name of a book that doesn't explain MVC 4 by referencing other technologies that I have also never used. I've looked through articles, articles and tutorials on everything from MSDN to graduate papers and I just don't get it.
I know what MVC the design pattern is, but one of the main things I can't get a straight answer to is what the difference is between MVC the pattern and MVC 4 the framework. As a web developer, will I ever have to change or make use of the frameworks, or is it something that is supposed to "stay out of your way" (to quote another SO post.) Is it something that gets generated by VS and I will never have to touch?
Again, I'm sorry if this is obvious, maybe I'm trying to make this more complicated than it actually is. All I have been looking for is a straight forward answer with concrete examples that don't contradict or complicate it any further.
Please...I'm at my wits end here. My last question was apparently too vague and got voted down and closed, so I tried to be more specific, but part of my problem is what are the right questions to ask.If there is anything that can say to clarify,please tell me.
I certainly don't want to discourage you any more than you appear to be at the moment, but in my opinion, if you can't make head or tail of the huge amount of material that already exists on MVC, then perhaps you are just not ready for it yet. That's OK - in fact Microsoft recognise that MVC is complicated, which is why they introduced the ASP.NET Web Pages framework (which is what gave birth to Razor syntax).
My advice would be to follow the link and download WebMatrix. Then follow some of the Web Pages tutorials. That way you can get your head around Razor without worrying too much about MVC for the time being.
Incidentally, ASP.NET MVC is a web development framework that enables you to build web applications based on the MVC pattern. You need to understand how MVC works in order to make use of the framework. You need to understand what Models are, what Views are and the role that Controllers play in the whole thing.
The framework itself is not an example of MVC.
Razor is a templating syntax that allows you to intermix C# (or VB) with HTML to output dynamic content in a View in MVC or a page in the Web Pages framework.
I know it may seem confusing, but it seems to me that you are over complicating things.
The simple matter is that MVC is a design pattern. That is, it's an abstract thing.. a philosophy of sorts. It's not a concrete thing. A design pattern simply gives you a description of how the pattern is supposed to work, and while it may give you a sample implementation, in general it leaves that implementation up to you.
ASP.NET MVC (whichever version) is a specific application framework that uses the MVC pattern as its basis. In other words, it's a concrete implementation of the MVC design pattern.
In fact, the ASP.NET MVC implementation isn't even a "true" implementation of the MVC design pattern, as certain compromises are necessary to make it work in a web based model. So it's really more "MVC design pattern inspired".
You're overthinking things. Just accept that ASP.NET MVC is a framework library that implements and MVC design pattern.
As for Razor, it's merely a templating library. That is, it allows you to define a page layout as text, and insert values at specific places (place-holders). It also allows code to be executed during the process of rendering a template, although this is discouraged in MVC except for very simple cases.
Razor is also used in ASP.NET WebPages technology, in those cases it tends to be more like PHP or classic asp in that all code exists in code blocks within the template itself. Both ASP.NET and WebPages use the Razor templating engine (also called a View Engine) but they use them in different ways.
Related
Ive been doing a bit of research / reading into mvc recently and was just wondering what the main purpose is.
is it as some people say to seperate the logic from the html
or to create clean url's
i could be missing the point completely, but asp.net forms really seperates the logic from the html and if you just want clean url's why not use a mod_rewrite rule?
MVC is a software engineering concept which is used more widely than just in ASP.net.
In a nutshell it encourages strong separation of:
business logic (the Model) the code which does all the brute force work behind the scenes; dealing with the database, performing large calculations; and
user interface logic (the View) the code which presents information to your users in a pretty way.
The C is for Controller - the ligaments that bind the bones of the model and the muscles of the views and allow them to communicate with each other cleanly.
You are correct that 'normal' ASP.net uses code-behind files so that page markup is kept separate from the code that generates that markup (in contrast to languages like PHP where code is embedded directly amongst HTML), but MVC ASP.net encourages even more separation in the ways I described above.
Take a look at this tutorial for a more detailed discussion of the pattern. Also take a look at this SO question
The MVC pattern has nothing to do with rewriting URLs. ASP.net MVC might make this easier but that is not by any means it's main purpose.
Testability is a big benefit of using ASP.NET MVC. It is non-trivial to write unit tests for ASP.NET winforms. It is much easier to unit tests for Controllers.
If you are doing MVC correctly, your views should be very light, and a lot of your logic is implemented in the Controllers.
Let me compare the two for you:
Asp.net web forms
They matured the old ASP technology that was much more like PHP. Code and presentation were piled up in the same file. Asp.net web forms upgraded this model by providing a mechanism of separating the two. But they built on top of the good things that windows application developers had. The drag drop interface creation with control events just like they exist in a windows application. Event thought code was separate from HTML, they were not separated. You still reference a lot of view controls in your codebehind, hence they're still very much bound to eachother.
Therefore it was rather easy to start developing on Asp.net web forms. But non savvy developers soon got to a bottleneck they didn't know existed (like slow postbacks due to huge view state etc.). Technology used some tricks to make this work. But on a serious large scale application this became quite a problem. Developers had to mingle their code to make it work with Asp.net web forms framework. Their complex forms had complex codebehinds with hard maintainable code with complex state.
The good (as well the bad) thing were at that time rich server controls. Nowadays with web 2.0 they don't seem rich anymore since they don't actually support client side functionality as much as they should. So Microsoft decided to also cram in something else. Update panels. That made partial rendering (and Ajax) possible with almost a flick of a finger. But it came with a cost. Everyone that used (uses) it soon realised it's not a viable solution that a professional application could implement.
Asp.net MVC
Now we have a new technology that doesn't have much in common with Asp.net web forms except for its first part of the name. MVC framework actually does separate code from user interface (view). Controller actions (code that executes on any HTTP request) is kept small and doesn't do anything with visualisation (it doesn't bind data to certain controls etc.). Controller action barely prepares data for the view to either consume or not. It's up to the view. Controller code doesn't in any way shape or form reference any view controls or anything. They're actually separate in MVC.
Views on the other hand just display and provide data. They can be partially or fully rendered. They support Ajax functionality to the point that everyone would like to use. Actually everything is separated into basic little things. Divide et impera (divide and conquer) seems to be the save-line here.
There's not hidden functionality. No flirting with windows development. It pure request response framework. Developer has the ability to 100% control the visual aspect of their app. But for the cost of not having rich controls out of the box. Those may be provided by the community or some developers prefer to create per purpose controls that serve the process much better.
Which one is better then?
Both have their pros and cons. But if you decide to build a semi complex, modern and maintainable application I'd suggest you give MVC a go.
But if all you need to do is a 15 screens application (without any particular interface requirements) it would be much faster to create it using Asp.net web forms.
MVC is a design pattern. Its purpose is to separate business logic and presentation details.
ASP.Net MVC is a mechanism to create web applications using ASP.Net and the MVC pattern.
One of the features of ASP.NET MVC is the ability to use SEO friendly URLs to provide commands to the controller part.
You can do as you have stated but ASP.Net have provided you a mechanism to do this easier.
The way ASP.Net Webforms was designed is that it made it easy for you drag controls on to the web form and code the logic underneath. ASP.Net MVC is designed so you separate your concerns easier.
The URL part of the ASP.NET MVC framework is just a modern phenomena to produce search engine friendly urls. They've infact been around long before the Microsoft team decided to add them to the framework (which required IIS7 before it could be done with no IIS extension).
The greatest pros in my view come from being able to test more easily, and separating off the parts of your application more cleanly. The whole ActionResult architecture of the ASP.NET MVC framework makes it very easy to switch from AJAX to plain out POSTs.
Delphi 5 use to employ the MVC model for its ISAPI extensions, 10 years ago.
MVC is not just an ASP.net thing, it is a design pattern that was widely accepted before it was created within the .NET framework, the thing about MVC is the separation of data from presentation(user interaction) from the business layer. It was just a way for Microsoft to offer that type of design pattern under the .NET framework
Although guys before me already give enough answers to the queston of purpose of ASP.NET MVC there is one thing I would like to add.
The ASP.NET Web Forms tried to abstract html and web from web development. That approach lead to the lacks in performances and usage of rich javascript frameworks.It was possible to create web application without actual knowledge of the web.
And to answer to you initial question, the purpose of ASP.NET MVC, I'll quote Dino Esposito:
With ASP.NET MVC, you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, total script and CSS freedom.
MVC existed long before people tried to use it in HTML pages. The main reason for MVC is to get a grip on the logic to drive your application. MVC allows you to clearly separate things that should be separate: The model, code which converts the model value for the display and the code which controls the model.
So this is not related to HTML or URLs in any way. It's just that MVC makes it really simple to have clean HTML and simple URLs.
I'm a big fan of what ASP.NET MVC is doing, on many levels.
I'm about to take part in re-build of a very highly trafficked website, and I'm not which framework would be best (if any).
The site will need the following:
To support Javascript-heavy, highly interactive pages
But at the same time, provide underlying semantic HTML for search engines
Support multiple languages
Be skinnable
Expose a RESTful web-service API for partners
As far as I can tell, there's no reason not to use ASP.NET MVC for this.
I can present semantic HTML and layer Javascript on top using jQuery.
Multiple languages can be catered for using Resource files (same as at present).
Skinning can be done with CSS (it won't involve changes to the markup).
I can centralize business logic so that the Controllers and the WCF web-service use the same code.
But are there potential drawbacks to using MVC that I haven't considered?
I don't want to be the guy who picks a technology because it's cool but finds later down the track that it isn't very suitable for the job.
ASP.NET MVC is not good when all your doing is making a website that needs server-side code (but that's also true about ASP.NET also).
In your case I think MVC would be a great way to go. MVC has proven itself on high traffic websites (e.g. this one). However you must remember that MVC is new and changing. A library may not exists to do a specific task which means you'll have to write that code yourself.
Good luck on your rebuild!
You're good to go with MVC given what you've said about your project.
As far as I'm concerned, ASP.NET MVC is really only NOT good for situations where you have a large codebase in WebForms (meaning you have a lot of ASP.NET user controls, custom controls, etc). It's also not good if you are going to have people working on it who don't know what it's all about. Other than that, it's a pretty nice technology.
My two cents:
ASP.NET MVC is a great option but there is a little learning curve involved, so make sure your project plan/timeline has this handled. There might be developers on your team who might not be comfortable working with ASP.NET MVC, and this can cause possible delays (a lot of developers are still working in ASP.NET 1.1!).
#Alex: Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
IMO the idea of using controls in ASP.NET MVC doesnt make much sense. You can create a treeview control using jQuery easily. Classic ASP.NET server controls carried a lot of baggage (viewstate etc) and hence ASP.NET MVC did not use any of those controls (though you can use helpers).
Finally, ASP.NET MVC is an alternative, not a replacement to Web Forms. I would not use ASP.NET MVC as it is still evolving, and my team is not very comfortable with it, but I guess slowly more and more programmers would shift to this (better) option.
I do not like ASP.NET MVC because of following reasons:
1.
Ugly routing API, there http://ayende.com/Blog/archive/2008/11/05/a-case-study-of-bad-api-design-asp.net-mvc-routing.aspx
is description of what is wrong.
By the way, friendly urls can be easily implemented without mvc
http://demo.liveui.net/bugtracker/Tasks/7
2.
Poor object model. It is proved that good software should consist of reusable components. There is nothing that can be reused in ASP.NET MVC based web site. For example, if you implemented smart drop down list once it will be difficult to use it again (even on the same web site).
3.
Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
If I were you I would try to find some CMS and customize it for WebSite needs.
To responses:
YES. I know about ASP.NET controls disadvantages, but the question is about ASP.NET MVC. One can write a book about what is good and what is bad in ASP.NET but I do not think it is appropriate to discuss it here.
There are better ways of implementing MVC without using asp.net MVC. I have done it in the past, even before asp.net MVC came live. MVC is a pattern, not a technology, I do not understand why some people call it a Technology. You can separate all concerns by removing the code-behind from webforms and create your own controllers and routers and you will still have the advantage of the webform controls, etc to which most asp.net developers are used to use. asp.net mvc is nice for people whom do not really have the time to properly create an MVC app in a webforms environment and also to those whom do not have the time to architect a better solution. in conlcusion, asp.net mvc is good but there is a much better way of doing it and finally, MVC is NOT a technology.
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/
I've noticed a lot of talk about asp.net MVC lately, but I haven't come across a clear or compelling description of when, where or why I would want to use it over WebForms.
Let's say I wanted to build a small web application that allows a person to advertise some items online. The website will have 4 use cases:
Search adverts
View listings
View item
Place an advert
Let's assume:
I'm not particularly interested in unit testing my controller. The page will either render the list of items correctly, or it won't.
I am interested in more control over the HTML markup.
I'm not interested in using the latest buzz technology just for the sake of it.
I am interested in using the tool that is best suited to the job in terms of productivity, performance, maintainability & simplicity of the end solution.
I don't want to have to work around a bunch of nuances to get something simple to work.
So, my questions are thus:
What are the fundamental differences between the two models?
In which scenario is one better than the other?
What are the gotchas with asp.net MVC (I'm aware of the gotchas with WebForms)
For our sample app, what would I gain by using asp.net MVC instead of WebForms?
For our sample app, what would I lose by using asp.net MVC instead of WebForms?
Is it feasible to mix and match models within the same small application?
Thanks to anyone who spends the time to contribute an answer.
What are the fundamental differences between the two models?
WebForms try to mimic WinForms development by allowing you to reuse lots of pre-made controls, and by faking web application state via the hidden _VIEWSTATE mechanism.
MVC is a pattern designed to help you separate your data (Model), business logic (Controller) and presentation (View). It adheres more to the true nature of the web : RESTful URLs, stateless.
In which scenario is one better than the other?
In my opinion, for an intranet application making heavy usage of controls, WebForms can be useful at reducing development time, because thanks to the designer you can create your UI very quickly and let the framework manage the app's state automatically.
For any other project, especially a public website, even a small one, I think MVC is the way to go.
What are the gotchas with asp.net MVC (I'm aware of the gotchas with
WebForms)
I'd say there is some learning curve to fully understand the MVC pattern and its power. Also, since the framework is still in BETA you can expect the API to experience some minor changes before release.
Since JavaScript is not hidden from you in MVC, it would also require some time to learn if you're not familiar with it. jQuery greatly simplifies this though.
For our sample app, what would I gain by using asp.net MVC instead of
WebForms?
You'd gain better control over HTML markup and Javascript behavior, a cleaner separation of concerns and some easily testable codebase (even if you don't seem interested in unit testing it).
For our sample app, what would I lose by using asp.net MVC instead of
WebForms?
You'd lose the 'drag and drop' quick way of building your pages and the application state management.
Is it feasible to mix and match models within the same small
application?
In some ways, yes it seems.
I'd recommend watching this talk by Phil Haack, who gives a good overview of the framework and invites Jeff Atwood to talk about how he built StackOverflow with it.
He explains how SO is using some WebForms controls for CAPTCHAs which render themselves into the view.
The primary difference is that MVC is more like "regular" web development that the rest of the programming world uses, whereas standard ASP.NET was designed to make it brain-dead easy for Windows developers to become web developers. I learned web programming by learning Ruby on Rails, and MVC seems like it is becoming the .NET version of Rails.
MVC is much more oriented around standards compliance, unobtrusive javascript, and separation of concerns than regular ASP.NET. You'll need to understand how HTML and CSS work together. You'll learn a LOT more javascript as you master MVC. One of the biggest advantages of MVC to me is that you can use jQuery to do some amazing AJAX stuff easier and BETTER than you can in regular ASP.NET.
If you're just now learning web development then I strongly encourage you to learn MVC. You'll be able to transfer at least some of your new skills to other frameworks in the future.
If you're looking for which to learn to quickly get a web development job, then I'll have to strongly suggest ASP.NET.
Once MVC is RTM'd I think we will see a slow and steady adoption curve and as it matures MVC may become the primary framework for creating websites with ASP.NET. I hope so at least!
The biggest difference between ASPNET MVC and is WebForms is the lifecycle of an page, no difficult(unnecessary) postbacks, clean coding, enz.
There are no rules for that
???
REST-full website, Separation of logic
Design-time support, can't use third-party webcontrols
Please don't mix it together. If you really want to use the WebForms model you could use the MVP pattern, Billy McCafferty wrote exellent articles on that design pattern
I'm redesigning some of my applications from the MVP-pattern to MVC-pattern, not because MVC is better but I would like to use the newest techniques offered by MS(pattern itself is quite old).
I just listened to the StackOverflow team's 17th podcast, and they talked so highly of ASP.NET MVC that I decided to check it out.
But first, I want to be sure it's worth it. I already created a base web application (for other developers to build on) for a project that's starting in a few days and wanted to know, based on your experience, if I should take the time to learn the basics of MVC and re-create the base web application with this model.
Are there really big pros that'd make it worthwhile?
EDIT: It's not an existing project, it's a project about to start, so if I'm going to do it it should be now...
I just found this
It does not, however, use the existing post-back model for interactions back to the server. Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).
How would that work? No viewstate? No events?
If you are quite happy with WebForms today, then maybe ASP.NET MVC isn't for you.
I have been frustrated with WebForms for a really long time. I'm definitely not alone here. The smart-client, stateful abstraction over the web breaks down severely in complex scenarios. I happen to love HTML, Javascript, and CSS. WebForms tries to hide that from me. It also has some really complex solutions to problems that are really not that complex. Webforms is also inherently difficult to test, and while you can use MVP, it's not a great solution for a web environment...(compared to MVC).
MVC will appeal to you if...
- you want more control over your HTML
- want a seamless ajax experience like every other platform has
- want testability through-and-through
- want meaningful URLs
- HATE dealing with postback & viewstate issues
And as for the framework being Preview 5, it is quite stable, the design is mostly there, and upgrading is not difficult. I started an app on Preview 1 and have upgraded within a few hours of the newest preview being available.
It's important to keep in mind that MVC and WebForms are not competing, and one is not better than the other. They are simply different tools. Most people seem to approach MVC vs WebForms as "one must be a better hammer than the other". That is wrong. One is a hammer, the other is a screwdriver. Both are used in the process of putting things together, but have different strengths and weaknesses.
If one left you with a bad taste, you were probably trying to use a screwdriver to pound a nail. Certain problems are cumbersome with WebForms that become elegant and simple with MVC, and vice-versa.
I have used ASP.NET MVC (I even wrote a HTTPModule that lets you define the routes in web.config), and I still get a bitter taste in my mouth about it.
It seems like a giant step backwards in organization and productivity. Maybe its not for some, but I've got webforms figured out, and they present no challenge to me as far as making them maintainable.
That, and I don't endorse the current "TEST EVERYTHING" fad...
ASP.NET MVC basically allows you to separate the responsibility of different sections of the code. This enable you to test your application. You can test your Views, Routes etc. It also does speed up the application since now there is no ViewState or Postback.
BUT, there are also disadvantages. Since, you are no using WebForms you cannot use any ASP.NET control. It means if you want to create a GridView you will be running a for loop and create the table manually. If you want to use the ASP.NET Wizard in MVC then you will have to create on your own.
It is a nice framework if you are sick and tired of ASP.NET webform and want to perform everything on your own. But you need to keep in mind that would you benefit from creating all the stuff again or not?
In general I prefer Webforms framework due to the rich suite of controls and the automatic plumbing.
I would create a test site first, and see what the team thinks, but for me I wouldn't go back to WebForms after using MVC.
Some people don't like code mixed with HTML, and I can understand that, but I far prefer the flexibility over things like Page Lifecycle, rendering HTML and biggy for me - no viewstate cruft embedded in the page source.
Some people prefer MVC for better testibility, but personally most of my code is in the middle layer and easily tested anyway...
#Juan Manuel Did you ever work in classic ASP? When you had to program all of your own events and "viewstatish" items (like a dropdown recalling its selected value after form submission)?
If so, then ASP.NET MVC will not feel that awkward off the bat. I would check out Rob Conery's Awesome Series "MVC Storefront" where he has been walking through the framework and building each expected component for a storefront site. It's really impressive and easy to follow along (catching up is tough because Rob has been reall active and posted A LOT in that series).
Personally, and quite contrary to Jeff Atwood's feelings on the topic, I rather liked the webform model. It was totally different than the vbscript/classic ASP days for sure but keeping viewstate in check and writing your own CSS friendly controls was enjoyable, actually.
Then again, note that I said "liked". ASP.NET MVC is really awesome and more alike other web technologies out there. It certainly is easier to shift from ASP.NET MVC to RAILS if you like to or need to work on multiple platforms. And while, yes, it is very stable obviously (this very site), if your company disallows "beta" software of any color; implementing it into production at the this time might be an issue.
#Jonathan Holland I saw that you were voted down, but that is a VERY VALID point. I have been reading some posts around the intertubes where people seem to be confusing ASP.NET MVC the framework and MVC the pattern.
MVC in of itself is a DESIGN PATTERN. If all you are looking for is a "separation of concerns" then you can certainly achieve that with webforms. Personally, I am a big fan of the MVP pattern in a standard n-tier environment.
If you really want TOTAL control of your mark-up in the ASP.NET world, then MVC the ramework is for you.
If you are a professional ASP.NET developer, and have some time to spare on learning new stuff, I would certainly recommend that you spend some time trying out ASP.NET MVC. It may not be the solution to all your problems, and there are lots of projects that may benefit more from a traditional webform implementation, but while trying to figure out MVC you will certainly learn a lot, and it might bring up lots of ideas that you can apply on your job.
One good thing that I noticed while going through many blog posts and video tutorials while trying to develop a MVC pet-project is that most of them follow the current best practices (TDD, IoC, Dependency Injection, and to a lower extent POCO), plus a lot of JQuery to make the experience more interesting for the user, and that is stuff that I can apply on my current webform apps, and that I wasn't exposed in such depth before.
The ASP.NET MVC way of doing things is so different from webforms that it will shake up a bit your mind, and that for a developer is very good!
OTOH for a total beginner to web development I think MVC is definitely a better start because it offers a good design pattern out of the box and is closer to the way that the web really works (HTML is stateless, after all). On MVC you decide on every byte that goes back and forth on the wire (at least while you don't go crazy on html helpers). Once the guy gets that, he or she will be better equipped to move to the "artificial" facilities provided by ASP.NET webforms and server controls.
If you like to use server controls which do a lot of work for you, you will NOT like MVC because you will need to do a lot of hand coding in MVC. If you like the GridView, expect to write one yourself or use someone else's.
MVC is not for everyone, specially if you're not into unit testing the GUI part. If you're comfortable with web forms, stay with it. Web Forms 4.0 will fix some of the current shortcomings like the ID's which are automatically assigned by ASP.NET. You will have control of these in the next version.
Unless the developers you are working with are familiar with MVC pattern I wouldn't. At a minimum I'd talk with them first before making such a big change.
I'm trying to make that same decision about ASP.NET MVC, Juan Manuel. I'm now waiting for the right bite-sized project to come along with which I can experiment. If the experiment goes well--my gut says it will--then I'm going to architect my new large projects around the framework.
With ASP.NET MVC you lose the viewstate/postback model of ASP.NET Web Forms. Without that abstraction, you work much more closely with the HTML and the HTTP POST and GET commands. I believe the UI programming is somewhat in the direction of classic ASP.
With that inconvenience, comes a greater degree of control. I've very often found myself fighting the psuedo-session garbage of ASP.NET and the prospect of regaining complete control of the output HTML seems very refreshing.
It's perhaps either the best--or the worst--of both worlds.
5 Reasons You Should Take a Closer Look at ASP.NET MVC
I dont´t know ASP.NET MVC, but I am very familiar with MVC pattern. I don´t see another way to build professional applications without MVC. And it has to be MVC model 2, like Spring or Struts. By the way, how you people were building web applications without MVC? When you have a situation that some kind of validation is necessary on every request, as validating if user is authenticated, what is your solution? Some kind of include(validate.aspx) in every page?
Have you never heard of N-Tier development?
Ajax, RAD (webforms with ajax are anti-RAD very often), COMPLETE CONTROL (without developing whole bunch of code and cycles). webforms are good only to bind some grid and such and not for anything else, and one more really important thing - performance. when u get stuck into the web forms hell u will switch on MVC sooner or later.
I wouldn't recommend just making the switch on an existing project. Perhaps start a small "demo" project that the team can use to experiment with the technology and (if necessary) learn what they need to and demonstrate to management that it is worthwhile to make the switch. In the end, even the dev team might realize they aren't ready or it's not worth it.
Whatever you do, be sure to document it. Perhaps if you use a demo project, write a postmortem for future reference.
I dont´t know ASP.NET MVC, but I am very familiar with MVC pattern. I don´t see another way to build professional applications without MVC. And it has to be MVC model 2, like Spring or Struts. By the way, how you people were building web applications without MVC? When you have a situation that some kind of validation is necessary on every request, as validating if user is authenticated, what is your solution? Some kind of include(validate.aspx) in every page?
No, you shouldn't. Feel free to try it out on a new project, but a lot of people familiar with ASP.NET webforms aren't loving it yet, due to having to muck around with raw HTML + lots of different concepts + pretty slim pickings on documentation/tutorials.
Is the fact that ASP.net MVC is only in 'Preview 5' be a cause for concern when looking into it?
I know that StackOverflow was created using it, but is there a chance that Microsoft could implement significant changes to the framework before it is officially out of beta/alpha/preview release?
If you are dead set on using an MVC framework, then I would rather set out to use Castle project's one...
When that's said I personally think WebControls have a lot of advantages, like for instance being able to create event driven applications which have a stateful client and so on. Most of the arguments against WebControls are constructed because of lack of understanding the WebControl model etc. And not because they actually are truly bad...
MVC is not a Silver Bullet, especially not Microsoft MVC...
I have seen some implementation of MVC framework where for the sake of testability, someone rendered the whole HTML in code. In this case the view is also a testable code. But I said, my friend, putting HTML in code is a maintenance nightmare and he said well I like everything compiled and tested. I didn't argue, but later found that he did put this HTML into resource files and the craziness continued...
Little did he realized that the whole idea of separating View also solved the maintenance part. It outweighs the testability in some applications. We do not need to test the HTML design if we are using WYSWYG tool. WebForms are good for that reason.
I have often seen people abusing postback and viewstate and blaming it on the ASP .NET model.
Remember the best webpages are still the .HTMLs and that's where is the Power of ASP .NET MVC.