Related
Hypothetical scenario:
I want to create a web app that will rely heavily on the display of tabular data. The GUI should allow for resizing or columns, grouping by columns using drag and drop and on the fly filtering.
If I went with Web Forms, I know I could buy Telerik and other 3rd party controls to give me this functionality with relative ease. If I went with Razor, I think I would be up the creek trying to strengthen my underdeveloped client side coding skills and would end up with an inferior interface in the end.
I've read about some of the advantages of Razor and its cleanness is compelling, but are there no grid components that would give me rich features like those described above with low development cost, i.e., do I have to write them myself?
I read many of the postings here about Razor and didn't quite see this question addressed, I hope its not really a duplicate.
in fact Telerik, DevXpress, Infragistics, they all have grids for MVC with native filtering, grouping, sorting and I guess also column resize out of the box:
check here the DevXpress MVC extensions's GridView
Don't underestimate the learning curve of ASP.NET MVC 3. It's not as easy as the tutorials would have you believe, and it's very easy to get yourself into a mess with Razor, if you're not careful.
If you're comfortable with WebForms and know you can solve the task with relative ease using that technology, I would recommend staying with it for now.
There are lots of compelling reasons to use MVC, but you don't seem to mention any of them, other than "that's what the cool kids are doing". And that shouldn't be the primary reason. :)
I am not starting an argumentative discussion here and this post is not about career development, but from the commercial point of view:
If a company was using ASP.Net MVC as a main methodology to build their web sites and application.
However, ASP.Net MVC takes more time to show a functional application than ASP.Net Web Forms, for example, building domain models would take some time which obviously can't be represented on a UI at that current stage.
My question is, if a client wants to see a functional demo application (just a proof of concept) so he knows that the company he is dealing with is professional and capable of doing that. Would it be better to do that demo in ASP.Net Web Forms only to show the client, and then work on the real application using ASP.Net MVC? If not, what are the (quick) alternatives?, I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
WebForms being faster than MVC is a myth:
You are not required to have a domain model, just something that represents your database tables. This is the same in WebForms unless you are using SqlDataSource's.
The code in your !IsPostBack or btnSubmit_OnSubmit is almost identical to the HttpPost controller actions. Except with MVC you don't have to write left to write object.FirstName = txtFirstName.Text when you understand how UpdateModel works.
UI is UI. If you know HTML/CSS creating the UI is just as easy. Almost easier in MVC because you don't have to set control properties any longer and all UI can be done in one place.
Fast MVC comes from understanding how to get the most bang from your buck using EditorFor, DisplayFor templates. You'll need to know and understand how to customize your Object.ascx file. With this technique under your belt you won't have to create forms by hand anymore. 2 projects ago we had a site with 100% autogenerated forms. Change a class, change a form. Done!
Another helpful MVC tool is the DataAnnotations attributes. Validation made easy. Customizing these is really easy too. Just create your own ModelMetaDataProvider and starting expanding the validations your application can handle.
The only part of MVC that is slower is displaying a grid. MVC 3 already has a useful grid tool and MVCContrib has had a grid tool out for a year now. I ended up rolling my own, its very simple actually, loop through properties, write <td />'s. < 200 lines of code. This isn't really a benefit to WebForms either. To use WebForms grid components means giving up a lot of quality using ObjectDataSources and the like.
To summarize fast MVC comes from these different techniques:
Object.ascx
ModelMetadataProviders
UpdateModel
DataAnnotations
If you are more advanced and know ORMS like EntityFramework and how to use Automapper your probably going to be even faster.
You can get a demo up and running very quickly in MVC. I could put one together much quicker than with WebForms, and I am familiar with both.
The reliance on convention in MCV will help a lot, binding is based on the names of objects.
If i was creating a quick demo, i would just create a bunch of ViewModels with static data in them, different button clicks etc will just bind one of these ViewModels to the page.
Turbo Fast!
I build prototypes in excel. No logic, no code. just basically screenshots to show the user that we are communicating the same ideas. Create a worksheet for each "View" or screen you need to show. Client's usually only care how "pretty" an application looks vs does it work right.
This also is a benefit as you can include more non-technical users in the prototyping process, since most are used to excel. I can send you an example and the finished production web application, if seeing is believing. I personally learn best by example.
And to your post where you wrote...
I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
They need to have their expectations adjusted and managed. A lot of bad development has been done quickly over the years, which makes client's ask questions like "Bob did it in 1 hour'. To that I say, you can either have a lousy project fast, that you have to constantly duct tape or a well thought out and well written project that will only need to be enhanced as Bus Reqs change
I think the answer is obvious: use whichever you think makes you faster. There's no point in using MVC if you are faster in WebForms. Especially since this is for a throw-away demo.
I am trying to explain ASP.Net MVC 2 to my colleagues and the management. I have to develop a sample application in both ASP.Net and ASP.Net MVC 2 to show case the differences between the two.
What would be a good application that can bring out the differences between the two? I am planning to demonstrate performance and testability. Any other key points that I can demonstrate?
Any ideas is really appreciated.
If they're web developers that likes to keep up with all the latest stuff, show 'em your complete control over the generated source. Show them how they can create HTML5 compliant websites with no extra effort. No more (unless you want) viewstate or document wrapping form tags.
You could also show them the extensibility abilities with action filters and action results.
But, as you mentioned, the biggest win for everyone is testability.
Edit:
I can really recommend TardisBank as a great sample application. It uses MVC3 with Razor and RavenDB as the database. The code is well structured and clean.
Show them the page size, that should be helpful
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls
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.
Let's say that you will start a new ASP.NET web site/application tomorrow. Would you chose Web Forms or MVC, and why?
MVC baby! And JQuery!
Edit: OK, it's fair enough to say my response warrants a little more info.
I'd choose MVC for the following reasons:
I have worked in Rails and found it highly productive. ASP MVC has borrowed so much from Rails that it feels like a direct port in some ways (and that's a good thing in my mind).
AJAX is important, but I hate the Microsoft "Atlas" approach to AJAX (whatever the product name is these days). If you're going to do AJAX, you need to understand the HTML and the JavaScript. Frameworks that hide that from you are hurting you more than they are helping you (IMO).
JQuery has taken over the world it seems in terms of JavaScript frameworks. ASPMVC is well-integrated with it. I want to learn it, so there's great alignment here.
The whole "control" model is a neat idea, but it is more complicated than it appears on the surface. For example, look around on SO for questions about how a UserControl can find its highest level containing control and so forth. The control hierarchy abstraction has leaks in it. Grids are great if they do what you want out of the box, but it's very very hard to customize them to do something they weren't made to do. And the best grid controls on the market (the ones that are highly customizable) are large, bloated, overly complicated beasts. Maybe that shows us that we should drop back down to HTML and let loops in our views do that kind of thing for us.
I believe I can build complete, beautiful apps in ASPMVC much faster than in ASP.Net (and I've got some years of ASP.Net under my belt). Look at StackOverflow ... built quickly on ASPMVC with JQuery, and it's fast, scalable and a joy to use IMO.
Oh, and it's completely open source! It is ok to read the source code, blog about it, and even modify then redistribute it!
I would choose MVC simply because it's designed to be testable and mock'able. That would be the major factor in my decision.
WebForms are much more difficult to Unit Test because they're rooted in several concrete classes that are difficult, it at all possible, to Mock. These include HttpContext, HttpResponse, HttpRequest and HttpCookie.
MVC is designed to be testable and it's API greatly facilitates doing so.
Good article on the testability of MVC: http://dotnetslackers.com/articles/aspnet/ASPNETMVCFrameworkPart2.aspx
Personally, I have decided to use both...
If it's a website (viewed online), I have decided to use ASP.NET MVC.
If it was an application (web application with a single purpose) I have decided to use web forms.
This decision is purely based on the case use and the solution you trying to deliver. If you are interested in good SEO and a faster website, MVC is much cleaner HTML and faster than web forms.
However if you after a complex functionality with a lot of filters, grids, postbacks on the same page and you are well experienced in Web Forms, just stick with it.
If I were starting today I would probably still stick with webforms because of the volume of knowledge and resources surrounding it.
That said I really want to give MVC a shot and as others have mentioned the excitement within the community means it wont take long before there is a lot of support for it.
MVC FTW!, Reasons?
Total Control over my HTML
No Web Forms magic
No complex page life-cycles
Closer to the metal
It is the natural thing to use with HTTP
Is MVC the "flavor of the day", or does it have staying power?
I have worked with MVC, and have a vast amount of webform experience. I often wonder about the staying power of MVC.
You should consider this when choosing one or the other. What do you want to support for the entire product lifespan?
I can't say which I'd really go with having not tried MVC yet. But I'd be a bit worried about using it for a really big enterprise project as yet.
Scroll through pass questions and you'll see that there a lots of questions/issues with MVC (compared to good o' WebForms that is). That alone has me worried. And a lot of the questions seems to be for special UI needs. Again having not tried it I don't know how mature it is yet but I'd still be a bit worried.
Maybe someone who has used it for an enterprise project can shed some light.
While MVC is the new kid on the block there are still a lot of benefits to designing with the Web Forms model.
Familiarity with the tool
consistency of look/feel with existing projects
Tooling/designer
Postbacks
Event driven
Controls to abstract
3rd party controls that work
Rapid development
Declaritive style
Rachel Appel did a great presentation at MIX on this very topic. You can view the video here:
Choosing between ASP.NET Web Forms and MVC
http://videos.visitmix.com/MIX09/T23F
I would choose Webforms for local/intranet applications with rich business logic and MVC for public/internet site (blogs/forums/presentations/simple services). "WebForms application model" is preferable in areas where rich state support is critical
I have started a new Web site for our own product a week ago and I couldn't be happier with ASP.NET MVC. Everything seems natural, I always know where to go and look if something doesn't work or does not look the way I intended.
Frankly, the biggest chunk of time I've spent has been CSS. Coding, integration with jQuery... peanuts.
OTOH, if you are not experienced developer, ASP.NET will not appeal to you as it encourages you to go all the way and control all aspects of your site - HTML markup, CSS etc., which in turn means no controls, drag and drop visual editing etc.
Unlike traditional ASP.NET where you are left to yourself and often end up mixing all kinds of UI, persistence (DB) and business logic code in various pages, MVC will guide you and help you structure your app much more consistently. This will not sit with you if you don't like "opinionated" frameworks and/or just want to get the job done without caring about structure of the site, maintainability, scalability etc.
Note that it's perfectly possible not to care about this if all you're building is a one-off intranet site, but for public Internet site I'd choose MVC over classic ASP.NET every time.
MVC
... it just seems so obvious that's where the future is
In ASP.NET MVC you sacrifice your controls toolbox,
URL routing is already in ASP.NET (web forms)
So I would stick with ASP.NET web forms ( I'm not saying that MVC isn't good.)
jQuery, do you think the IT folks will let you use it?
ASP.NET MVC because I want to learn how to use it.
I would currently choose ASP.NET MVC for 2 reasons: 1) I want to learn to master it. 2) There is already a great community forming around ASP.NET MVC and everyone seems to have very positive entergy regarding it's use. I can't wait to see where it all ends up and I want to be part of it.
I would like to go with MVC. I always seam to be fighting the abstraction when I work with WebForms.
To use WebForms effectively you actually need to know more about how the web works than if you use something like PHP. I find myself using <asp:Literal instead of <asp:Label to avoid putting a <span> around the text and running labs to figure out the order of events, etc.
it really depends on the project, since i havent build anything with MVC and if the project has a short time delivery, i will probably find some hinders in MVC that could make me not to deliver the project in Time.
I wait for MVC on .net for a long time.
I think more than 90% people will choose MVC rather than webform.
If it was a personal project then I would use MVC. Just to learn more about it. If it was a project at work I would use WebForms, possibly in combination with DynamicData for the administrative parts. The reason is that I would be more productive with a technology I know, and using DynamicData for the administrative part would let me setup that part in minutes.
As always it depends upon the type of application you are developing and the individual circumstances. A lot of our internal applications are being developed in SharePoint as that is our internal platform of choice for intranet type applications.
This automatically limits us to ASP.Net on the standard model.
I really want to get to grips with MVC, but I don't have a justification for this at work and I have 2 kids and a wife at home so no time to develop at home.
Sometimes circumstances force your hand, if only we all had the choice of exactly what platform, framework etc. to develop with.
I am currently working on a project in Asp.net MVC with jQuery and jQuery-ui, and it's a lot of fun.
If you're familiar with html and javascript (or other MVC frameworks like rails), MVC makes much more sense than the old webforms. And you control the output, not some vague control on a form, so if there is an error on the page or if you want to change the layout you can :).
MVC. We're going to redo an application that is SEO intensive and MVC seams to fit right in out of the box. Plus I want to hang out with the cool kids on the playground.
I just released a major public site on the MVC platform after using webforms for all previous projects. Without a doubt it is the way to go, IMO.
With webforms, I have found the sites tend to become a mess over time as you have blocks of code in the code-behind that handles both view logic and controller logic. As the site grows and the logic gets more complex it is difficult to trace what is happening and where.
I find that that MVC forces you to break things up in a more logical manner. Controller and model classes allow you to get a better control on the organization of the application. In addition, views are more flexible because there is a specific way of providing data to them, through models.
Also, like others have mentioned, you have more control over the markup and urls and it plays nicer with client libraries like mvc.
The only time I would use MVC is if I was building and intranet site that was focused on reporting data of some sort where the built in controls that come with asp.net would save development time and I wasn't as concerned with the look and feel. I would never use asp.net webforms again for a major public facing site.
Both!
I am making the long haul to MVC. I have too much code that readily works in Web Forms. MVC is fantasic, but it sill leaves a lot in the productivty areas such as templated grids and lists, basic UI controls (calender, autocomplete, etc.) and scafolding. These are all areas where Web Forms excels at, but comes off the rails if you want precise control and want to keep things simple.
MVC 3 and EF Code-Only could be a great marriage if they are willing to bridge the gaps between the two. Most people that use Ruby use it for Rails, and ActiveRecord makes that easy to work with.
Also I would love to see a parallel "Feature Pack" project for MVC with MS support, similar to the way they did the Microsoft Ajax Toolkit, that would say have quarterly updates. I find MVC Futures and MVCContrib both lacking. But I know they only have so much budget. So, here's to hoping that MVC 3 changes all that.
Just say NO to ASP.NET MVC if you are developing for Intranet. For Internet, sure.
Hmm.. At the moment I am confused like you are and about to start building a new site :). I was going to start with Webforms, but now I see where the crowd is heading and I think I am going to give MVC a whirl now.
Thanks for asking this question.
Now that it's RTMed and now that there are some very good resources on it I would say ASP.net MVC would be my strong preference, but it's not cut and dried.
Web forms hasn't gone though, it's still there, it's still supported and I've worked on several major sites and used Web Forms very successfully, so if there were other external factors such as a customer preference, or perhaps a team that had solid Web Forms experience then I'd still be happy to work with Web Forms. That said I have already worked on one project with MVC (while it was still in preview), and I much prefer it - my reasons are similar to those given above so I won't repeat them all. I will say that if testability isn't the best reason it's certainly in the top one:).
I would choose MVC since designers and developers can work in parallel on the same project. Designers can work on the view part (JavaScript, CSS, HTML) while backend developers can work on the controller code.
I would like to be doing ASP.Net MVC, even though I'm still very new to MVC. But it's not to be in the foreseeable future.
I'm actually going to be starting a rebuild of a web site in the next couple of weeks that was horribly written in ASP.NET 2.0 and I am going to be using ASP.NET MVC. For a lot of the same reasons as above. I would rather not use custom .NET controls and handle the HTML/JavaScript (using jQuery) myself. I do a lot of Java web development as well so having a good understanding of the underlying HTML/JavaScript/CSS is important to me.