I am going through the free sample chapter that I talked about earlier. It’s one thick chapter (196 pages) but it’s really good to introduce concepts and features of the ASP.NET MVC framework.
I love it! I cannot say anything else when after a few years of WebForms and me not understanding I am back. I actually get this – no more funky event-firing and endless questions about which event is fired first.
On top of that the whole framework is built and works very well to be tested and built with TDD .
There are so many nice little features that I just cannot wait to know as the backside of my hand… UpdateModel and ModelState just to mention a few.
I am now halfway through and will continue to the end. I’ll get back to you if anything more great appears.
PS.
I think this is the way we will build web applications from now on. I know I will…
10 comments:
Are you sure? How much longer it will take to develop the same gridview style app in MVC? What if your boss is asking you to do a gridview and the deadline is EOW. I know I still love WebForm and I had no issue with the order of events. Maybe, you haven't invested enough time in webform to appreciate it. Now, you are ready to jump ship. People need to be patient with technology.
OK, the correct way of doing the asp.net development is to invest time learning codesmith. Once you do that, no matter what you do, MVC or Webform, it's not that different anymore. Remember, if you type too much code, you are doing something wrong. Especially, the database oriented apps. Don't let MVC slave you. You are the master of technologies.
Thank you for your comments!
I realized that I didn't explain my reasons enough for disliking the WebForm-model.
You are be right that I haven't tried ASP.NET MVC to great extend, but I can tell you that if I never ever see a WebForm again it will be too soon ;)
Actually I have never got them and the event-firing that goes on, especially if the GUI gets complicated with UserControls etc.
I am by no means a Web-guy, but I have none the less done web-development with WebForm off and on for about 5 years. And I share my "lack-of-confidence" towards the WebForms-model with a lot of my colleagues.
The point I tried to make was that from what I've seen so far ASP.NET MVC is far more easy to grasp, design (TDD) and build around, than the WebForm-model. For me that is;)
Again - thank you for thoughtful comments.
But I have yet to see a componentized approach for ASP.NET MVC. From what I have seen, the biggest issue with ASP.NET MVC is that you got a tangle of c#, Javascript and everything you do, you have to write more than double amount of the code than webform. TDD is good, but you will soon find out, you have to test and re-test what you don't have to test with Webform. You don't have to test gridview, dropdownlist, etc... which were tested and packaged well for you by, say, experts from Microsoft or other people who specialize in custom controls. With ASP.NET MVC, at least at this stage, you have to write your own gridview code and test it. I don't think it's a great way to spend your time when you have to solve business problems. I don't think any boss will be pleased if you told him that you needed 3 times the time to do what you used to do with WebForm. But I do see opportunity to use ASP.NET for Internet type of web apps, but not for Intranet, Enterprise apps.
Again - great input.
I agree and disagree with you. I agree that it's not wise to spend your customers time (and money) writing generic stuff such as GridViews and DropDownLists.
But, I think that we should cut the not-yet-born framework some slack here. It is still just in RC (Release Candidate) and built with extension and openness (is that even a word?) in mind.
I would be very surprised if we don't see loads of extensions coming up in a few months (here, here and here are a few starting points).
My point (before this interesting discussion started ;)) was that I prefer the ASP.NET MVC way of doing things:
- I actually understand it, after doing it for 1 month to compare with six years of WebForm-ing off and on...
- I think that the clear separation of concerns give you the opportunity to let the right people do the right stuff (you know; designers do UI-design, coders code etc)
- The ability to TDD all the way to the GUI is worth a lot.
My final point is a bit dodgy and very much my own opionion; I think that customer often order Web-GUI that is way to complicated. Web-GUI should be quite simple (not ugly, simple).
If you need complicated GUI, with Tabs in several levels, advanced grids etc. I think that there are other, better alterntives (Windows Forms, WPF and Silverlight). The Deployment agrument doesn't hold anymore.
Finally the ASP.NET MVC framework will not replace the WebForms model. It's a matter of taste and liking.
I like the ASP.NET MVC framework because I understand it. :)
I use WEB-FORMS and MVC apparently with all due respect you need to spend some more time with webforms. If you are doing any real programming, something more complex then the simple talking points website GU like to brag about such as nerd diner, MVC is probably the worse possible choice for web development. The amount of code, lack of UI control support and design tools make this product incomplete at best. UI validation and debugging are also issues. The only reason it even is called 1.0 was due to timing, it's so called release, with MIX.
I fully agree with the above comments that you will end up writing TONS of code if you go this route.
If you want a microsoft website use "WEB-FORMS" or you decide you want an MVC solution RUBY is a better option.
Don't WASTE your time on Microsoft MVC or belive the HYPE. It is all typical Microsoft Marketing Nonsense. Microsoft MVC is the "SINKHOLE" of web development in it's current state. Hopefully it will be put out of it's misery just like BOB and Vista in the near future.
This is turning out to be a very interesting discussion.
The first thing to note is that even Microsoft themself is not putting WebForms vs ASP.NET MVC. It's "an option" and has been compared to automatic (WebForms) and manual (MVC) transmission in a car. Read this for more information. You choose the one that you like.
Secondly I don't agree with this being a hype and sinkhole (although I laughed out loud when I read that last one :)). It's actually quite the opposite: for once Microsoft has created a framework that seems to be well accepted in many communities, even alt.net. Also the MVC is very open and can be extended in a great number of ways. Finally the source code is available for download and is open to anyone to contribute in (via a forum).
My third point is that the framework still is very young... Give it a break and follow on in the development surrounding it. See this.
Or just drop it and stay with WebForms if you like it. I sure know I never did and never will...
The pivotal point is that ASP.NET MVC is still in its infancy; it's fun playing with it, but entrusting it with your LOB, deadline-driven, end of year review critical applications, you are endangering you hair and sanity.
While Microsoft has stressed ASP.NET MVC is only an option, many enthusiasts, including many book authors have pronounced the death of WebForms. It's very unnerving and unsettling, considering the near death of linq2Sql. Sure, unless you have unlimited time and budget, be careful about jumping on the band wagon too quickly. Let the dust settle a little bit before using asp.net mvc in your production projects.
OK, I've worked with web forms since they were born. I've read everything I could get my hands on about user and custom server control development, about the 13, yes, 13, stages in the life cycle of a control. I've broken teeth getting client side code into and out of a server control, written my own ViewState implementations for custom controls, and still had to hack around with <asp:Literal> to get jQuery to work, or to get the damn site to pass any sort of XHTML validation.
All so the VB developers didn't need to learn HTTP.
For bog standard, line of business form based interfaces to your corporate DB then sure, knock yourself out. But if you actually give a rat's arse about what your site is going to look like, if you want it to render across multiple browsers without having to wait for MS to rewrite their control rendering code (or to go down the adapter route to change MS's table rendering into something vaguely W3 compliant. That's a real blast.)
So, just like the choice between good old VB itself and MFC/C++, the choice is between doing standard stuff that MS thought of and requires as little knowledge of what's actually going on as possible, versus knowing how your technology works, and working with it. Coplien described it as Fascist languages vs. Anarchic languages.
Web Forms make it easy to do 80% of what your average internal web site needs to do using relatively cheap people to get it done(and the corporation can dictate the browser...). But the interesting work, and all the innovation, is happening in the other 20%.
As for the asinine comment that MVC is an inferior version of Ruby on Rails that requires a ton of code to get working, MS MVC learned tons from RoR - it would be stupid not to, and Ruby is a great language - that borrowed its share from Python and a whole ocean of functional languages. MS MVC also learned a metric butload from Smalltalk, and LINQ stole half its ideas from ML. Duh.
In short, and just to keep the rudeness factor all the way to 11, web forms are great if you don't know how the web actually works, don't care how to find out, and never learned to refactor code. If you are unfortunate enough to write boring, internal corporate web client versions of client server apps for a captive audience who can be told what browser to use and will put up with mediocre design and a late 90's page refresh experience, then web forms are for you. (and the URLs, oh God, the sharepoint URLs....)
If you actually know how to program, and are capable of learning how HTTP and HTML work, then MVC is a no brainer. If MS stopped supporting it tomorrow it would still be a no brainer. Routing URLs to controls (i.e. code that handles the URL) controls that access the data layer, and views that render the data just make sense. Having a framework that does that and that you don't have to write the documentation for yourself is a gift.
Oh yeah, it's really fun too. Like programming, only for the web.
Interesting Graham,
I think you may very well have a point here in that your liking of ASP.NET MVC or not may have to do with where you come from.
Are you a code-junkie like me then you probably love the nice separation of concerns that ASP.NET MVC supplies.
If you on the other hand want to whip something together without having to look to much on the code or the architecture, then the WebForms model should be sufficient.
Thank you for you comment.
Post a Comment