I have just started looking into .net MVC and I really like it.
There are a few developers within our team who think the same. But before we are allowed to use it for any project we need to get the approval of management.
What would be the best way to convince management(which know little about programming) that this would worth while and it could have some cost benefit?
My belief is that it will force us to write better more accessible sites which are a lot more testable than web forms. Which in return would mean less bugs and higher customer satisfaction. But I have no evidence of this.
EDIT:
We have a team meeting in 4 days, this is where I will be making my pitch to the team and management.That gives me two weeks to learn more on MVC and do a presentation.
Ok, I'm a manager. I've been one for more than 10 years. Luckily, I've been able to stay very current with my technology passions, so I think I can speak from both sides of the fence.
Managers are going to be concerned with three things here: risk, cost, and the status quo. So, when you present your plan, you're going to need to address each of these:
Risk:
Explain to them that the risk here is very low.
MVC2 is just an extension of MVC, both of which has full source code available (management speak: if we find a problem, we don't need support. We can fix it ourselves).
There's a ton of community support. (management speak: I can go online and get answers to any questions I have in a matter of minutes).
Heavy-hitters at Microsoft are pushing this (management speak: Microsoft is encouraging their developers to use this technology).
Cost
Talk about the fact that the technology is free, with a ton of community support.
Be ready to talk about ramp-up costs for any developers that don't have MVC experience. They're going to be less productive at first. Let your manager know that the developers will come up to speed quickly, and that MVC provides more efficient coding approach than traditional web forms.
Be ready to talk about costs and risks associated with ongoing maintenance. If you've already got a ton of web forms out in the wild, this will present a second skillset that developers will need to maintain. Find ways to convince management that it will be possible to maintain this skillset.
Status Quo
Many people become managers because they want a level of security and control in their life. If this is the case with your manager, they'll be interested in maintaining a comfortable status quo, and not making significant changes. If that's true here, you need to make the case that this really isn't a major change from what's being done today. Assure them that you have a back-out strategy. Talk about how this is really a proof-of-concept for MVC use in your organization, and that management will have an opportunity to review the success of the project prior to you ever suggesting MVC become a standard.
Really what it comes down to is the fact that ASP.NET MVC forces developers to write better, more scalable, and easier to test code. It moves them away from the crapshoot that webforms often can be, and in a direction oriented toward quality architecture and good clean code that follows more rigid conventions.
One definite drawback of MVC is that the View structure required by the webforms view engine (default) encourages you to write spaghetti code in the views that is, at times, a nightmare to maintain. Given this fact, you might even want to pitch them with the new Razor View Engine that was recently announced. With it you can write some extremely clean view code that even the non-developers at your company could manipulate without bringing mass death and destruction to your application. Compared to the markup in the webforms view engine, Razor's markup is pretty much beautiful.
Also, check out this really solid blog post by my buddy Matt Hidinger which does a great job of breaking down why MVC is so awesome.
When you speak to management just be sure to emphasize the all good points mentioned so far, and then compare them to all the bad that webforms is/can be. Be practical and realistic; if you have enough people on your team that are ready to jump on board with MVC then it's pretty much the best possible decision you can make, in my opinion, anyway. You may even want to take a moment to show them some of the great sites that use it- like Stack Overflow.
Personally, I have launched about 15 separate sites built with ASP.NET MVC and as such I feel I have a pretty solid understanding of it. I can wholeheartedly tell you, from my experience, MVC is the best thing that ever happened to ASP.NET.
It really depends on what you're comparing it to, but assuming it's an alternative to webforms, a few items to mention:
better testability
more control over output, which can help target other devices
leverage existing knowledge of .net
MVC framework encourages you to write more structured, testable and, as a result, more maintainable code. As the biggest costs in development are in the debugging and maintenance, those benefits alone should be a good validation. That said, it's still possible to code crap in MVC and that shouldn't be overlooked. If your company has a lot of expertise in another development framework then you really need to address the deficiencies in that and how MVC can rectify those deficiencies.
I would start by looking up blog sites that support MVC and compiling some of the advantageous features of MVC. I would start with Scott Guthrie's initial blog post regarding MVC - it outlines some great features - http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx
If you are looking at trying to bring MVC in and need to convince management of the value, your best approach is too show how it can reduce long term support costs. Having an application that has well developed unit tests with decent code coverage can ensure quality over the life cycle of the application because you can higher level of confidence that changes you introduce have not broken pieces of the application. This doesn't negate the need to test the application, but you will find breaking changes faster. An approach utilizing MVC over MVC is a much more flexible platform for this testing.
There are many studies you can utilize that show the long terms support/maintenance costs of an application are often greater than the initial development costs. Stephen McConnell's Code First has a good discussion of this.
Good luck!
As opposed to what? Management would rather you wrote poorly-designed code? I'm surprised it's even an issue, in that whatever else they're asking you to do, by the current state of the industry, is self-evidently the wrong decision. If they know what MVC is, I can't see how any reasonable person would want you not to use it.
Sell it as an ASP.NET component, only made by Microsoft to incorporate some of the newer web 2.0 technologies moving forward. Tell them it will enhance maintainability while reducing development time. Tell them it uses existing infrastructure, and is more performant. Tell them it uses existing investments in training and software. Tell them it is more efficient, and makes it easier to fix issues and build enhancements. Tell them they'll get more out of their development team without allocating more resources.
Related
I want to learn a framework that promotes good programming practices and is respected by the programming community.
However, I also want a framework that I can use for a day job.
Which one would you recommend?
This question comes from my experience of learning the basics of Django because it was highly acclaimed by developers on Stack Overflow and Hacker News. However.. there's hardly any jobs in my area (NYC) that are asking for Django developers.
As a long-time ASP.NET guy, I've recently gone through a similar decision process to figure out what other web frameworks I should try. Here's what I learned so far which may apply to your case too:
framework/platofrm choices (and hence job opportunities) are highly regional-- the Bay Area job market differs alot from what you'll find in NYC, Chicago, Montreal, or London. Look at local job listings (craigslist and indeed are good places to start) to get a good sense at what's in demand.
similarly, usage varies alot based on the size and type of company. if you want to get a job in a large company, Spring MVC and ASP.NET MVC may be your best bets. In small companies, DJango and (especially) Rails seem to be on the rise.
usage also sometimes varies by industry. for example, many HR apps seem be to .NET based, while financial/banking apps seem to favor Java. if you want to work in a particular industry, check out what up-and-coming companies in that industry are using.
when investing your scarce time in learning something new, favor technologies which are on the upswing of the adoption curve (e.g. Rails) rather than frameworks with wider adoption which may not be growing as fast. Also be wary of very early or niche frameworks which may not ever gain wide adoption.
the one common thread between most (or almost all) frameworks gaining in popularity is that they're MVC frameworks and rely heavily on a solid understanding of REST. Learning those concepts in depth is a good idea.
before deciding to invest a lot of time in one framework, gain a basic understanding of several of them, so you can get a reasonable sense of what you like and don't about each-- and so if you end up applying for a job using a framework you haven't learned, at least you'll be able to talk intelligently about it.
If you focus on what you enjoy, you'll be more motivated to learn it. For example, personally I found Rails (regarless of employment opportunities) more interesting than Spring or Django, so I decided to focus on Rails first. Others may have different impressions-- follow your programmer instincts. That said, there are often few jobs using technologies you find fascinating, so try to strike the right balance: technology you like that many companies are actually hiring people to use!
once you answer the basic "what framework" question, there are many more questions lurking, including picking a javascript framework, validation framework, an ORM, etc. Don't worry too much about those choices yet-- when starting, just pick the default implementation for your framework. But as you get more advanced, the same argument about frameworks also hold for those other things-- e.g. it's useful to know a few ORMs.
Personally, I decided on this approach:
continue building stuff in what I knew best (ASP.NET) but transition all work to ASP.NET MVC, where I can better understand MVC and REST concepts which apply cross-platform
learn JQuery (again, platform neutral)
blow off the ORM choice alltogether for now-- too many other things to worry about
build a few projects in Rails, which is the framework I see used most in the newer SF-Bay-Area startups I've been looking at
learn the basics (e.g. read a book or two, try a few samples) about Python/Django, Java/Spring, and Groovy/Grails.
I've encountered real projects at cool, small companies using Django, Ruby on Rails and (eiuw!) even Zope. .NET is for teletubbies - I've only ever heard of it being used by big corporations that don't know better.
I would say that knowing two or three is better than knowing one that is widely used because you will gain a better understanding of how it works as a concept. For instance if you've only used Java, there is something probably missing in your understanding of OOP, because you're pigeon-holed into thinking about it in one way. If you already know Django though you Spring would probably be a good compliment to that.
i'd probably say ASP.NET MVC. I always see lots of .NET jobs around and this seems to be a solid framework which i think in fact powers all the stackoverflow family. As a PHP developer i must also make a mention of Zend Framework which is used by a number of big sites including bbc.co.uk and is now frequently mentioned in advertisements for PHP jobs.
I want to learn a framework that promotes good programming practices and is respected by the programming community. However, I also want a framework that I can use for a day job.
Sorry to be the bearer of bad news here, but those two desires tend to conflict. IMHO most business managers tend to go for (ugly) rapid development on top of CRMs or other higher-level 3rd party codebases. Building elegant websites from the ground up mostly happens in startups, or true web companies where the website is the sole product. There are not that many of those companies; and many of those that seem to fit are actually a mess on the inside, i.e. due to time pressure, messy legacy code and many other reasons you often don't get to write according to "good programming practices" anyway.
I agree with Kaleb Brasee that Java and .NET are the two main platforms when job availability is a priority.
Every job market is unique, so look at job openings in your area, or call a handful of recruiters and ask what they see a need for / could easily place you in a junior position for. What I'm seeing is that Microsoft Sharepoint is in demand, and a few other regional CMS'es are in demand (in Denmark I see Sitecore regularly).
I think ASP.NET MVC 2.0 together with MVC Areas and ASP.NET Dynamic Data will have a good story, a good solution, for many of those bosses who want rapid development. And I think the resulting code could be quite okay, or at least not bad compared to many of the "CMS beaten into something else" sites that exist. But this is a brand new thing for the .NET platform, and it will need to be sold to the decision makers first...
Bottom line: If you want job security first and foremost, then look at large CMS's like Sharepoint, and work on other technologies in your spare time. Optionally you could take a job at a startup / a web company later; but look before you leap.
Have you tried Spring MVC? Many companies do use Java for web-apps (or .NET) and web service based applications.
Since you mentioned Ruby on Rails, you might want to learn Ruby on Rails. It has got some good programming practices in it and a very well thought architecture. The Ruby community itself have also (in my personal opinion) created very innovative frameworks and highly favor testing and quality. You can see this by the innovative testing framework like Cucumber, webrat, shoulda, coulda, rspec, test/spec. Many startups also uses Rails as their platform, so it should be easier for you to get a job. You can start looking at Working With Rails and 37signals job board. So there is a good ecosystem inside Rails and Ruby community.
But the downside of Rails compare to Django is mainly there are too much magic (less explicit) and the docs is not as good as Django. If you want to get a Django job, try looking at several news site because Django grew up from a newspaper site so it is adopted alot in news based sites.
I would recommend ASP.NET MVC, Ruby on Rails, or Python/Django, they all seem to be popular and successful, and based on the MVC paradigm which is definitely the right tool for the job when it comes to the web.
.NET and Java are by far the 2 largest platforms used by employers, and hence the most in-demand when searching for a job. Java has a few popular frameworks, with JSF, Spring MVC and Struts all seeming to be about equal in demand. I don't use .NET, but from what I've seen, ASP.NET and ASP.NET MVC are the major ones.
I would say that most of the frameworks mentioned here promotes good practices. But that doesn't neccesarily mean that the companies using those frameworks are actually following those good practices! In fact most probably aren't. So don't expect too much.
You see, places like Stack Overflow, Hacker News etc. are a great way to connect with people who really care about their craft. Sadly this is a minority. There are millions of programmers in the world. Most of them suck. The code they write sucks. They don't care. They are not interested in improving their skills. They just want to learn the bare minimum required to collect their paycheck, go home, feed the dog, spend some time with the family, watch some TV, go too bed and do it all over again the next day.
Okay that was a bit harsh :) What I'm getting at is that you are probably better off asking this question to some of the managers at the companies where you would like to work. My guess is that most of them will answer .NET or Java. If you are up for a laugh ask them why they chose that particular technology over something else, and see how many buzzwords they throw at you ;)
Whats the best way to go about upgrading a project with major design changes...in terms of project files (I guess)? I recently moved my website from ASP.NET to ASP.NET MVC and it was obvious that changes were so major it required a complete rewrite. Now I am preparing to move it to MVC 2, to take advantage of more features of the new framework, and again I am running into some road blocks which are moving me to do basically another complete rewrite. I would of course like to avoid this if possible because the site has grown quite large over time. I did do a good job of documenting the design decisions during the last rewrite however, and it would only take a few weeks to do another rewrite.
When do you need to make the decision to scrap the current project and bring everything up to the new technologies? If you create a new project file, whats the best way to handle migrating over the stuff that doesn't need to change from the old project?
You do a rewrite when the cost of maintaining and extending the current codebase outweighs the cost of debugging a new one.
How you determine the costs, however, is highly subjective.
You say "my website" which makes me think you are the personal owner of this website, as opposed to there being a paying customer who owns it.
If this is the case, I would say you may be talking things a bit too seriously. This sort of website is ideal for you to try out newer technologies so you can more completely understand the pros and cons.
So even if you need to completely rewrite to use MVC2, this is still a very valuable exercise. It's even more valuable if you also work on other customer owned websites.
The good/bad things you learn while working on your personal website give you great practical experience and help in deciding whether to apply it to customers real websites. Of course you could even learn, without a customer breathing down your neck, that a full rewrite to go from Web MVC to MVC2 is actually a bad idea (at least at this point in time).
Very rarely do I change technologies on an existing project as it's very hard to justify the cost to a customer. I could only imagine saying to a customer, at the end of this 2-3 week/month process, if you're very, very lucky you'll have exactly what you have now but law of averages you'll be further behind as it will have new bugs.
If a new module is being written then this may use new technology but the existing stuff is almost left as is.
I've been learning ASP.NET MVC for about a month now and I'm certainly sold on its benefits but I realize it is not applicable to all situations.
I've read in several places that ASP.NET MVC is not ideal for data-intensive applications:
Example 1: "Data Driven Application – life would be MUCH easier using WebForms if the application is data heavy"
Example 2: Nick Berardi's book suggests that you side with Web forms if your application is "data-heavy"
Can someone clarify as to why ASP.NET MVC is ill-suited towards data-heavy applications and why Web forms are more appropriate? Also, where does one draw the line between data-heavy applications and other applications? Are we talking quantity of data (millions of records) or are we talking large data models?
I would really like this clarified as well, as I have found the exact opposite to be true, and I think stackoverflow.com is evidence of the suitability of MVC to data-driven apps.
I didn't bother reading much of the second link, but the assertions in the first are not qualified, and many of them seem wrong to me. The stated weaknesses of WebForms, though, would be enough to drive me from using it for a data-intensive app:
UI logic coupled with the code, and thus is hard to separate.
Harder to unit test, so difficult to employ TDD.
Heavy page sizes due to view state management.
The stated weaknesses of MVC are quite flimsy:
Not event driven, so maybe difficult for people who know only Asp.Net Webforms to wrap their minds around it.
Third party control library support is not that strong.
No ViewState(this is also a strength).
The first one can be seen as a plus as much as minus. The second is just wrong as MVC apps can leverage traditional server-side controls if they wish, as well as make use of the rich library of client-side controls and libraries. The third, well I don't think I even need to speak to that one...
You have to be wary when reading articles like this on the internet - they sound authoritative and comprehensive, but where is the meat? Why are the stated weaknesses an issue? It is not enough to just throw opinion out there as fact. They should be backed up with metrics, such as when using platform x over y, developers unfamiliar with either platform were able to complete an application 30% faster, or platform x resulted in 25% fewer lines of code, or fewer levels of indirection, or whatever.
The idea that RAD is a plus is another one that bears careful examination: RAD is fast until you want to do something a particular control was not designed for, and then you hit a brick wall. It is a leaky abstraction and when it fails, you are suddenly confronted with the full complexity of understanding the design framework and code of the given control. This can be quite a setback, and the source code for these controls is not always available.
Doesn't make much sense to me. They might be speculating on the difficulty of creating many models if you have lots of different types of data, or perhaps the relative difficulty of creating web forms in MVC.
However, ORMs (such as L2Sql, EF and Subsonic), model binders, and form generators (I can't find the link right now) pretty much hose those arguments.
Frankly I don't buy it.
I believe that these authors are talking about the ability to drag/drop data controls onto the page such as GridViews, FormViews, and other databound objects.
Say you have a database for your IT department, with a table for computers, a table for printers, one for software, etc. The UI for this is a very simple data management system, essentially a glorified MS Access.
Rather than writing an elegant web app, with beautiful HTML and a class library, you could simply create a quick/dirty WebForms app by dragging your data sources and controls onto the page in Visual Studio.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
update: I know there is no one best way to do everything. Sorry for not saying that right off. In the context of the data-access tutorials, if you had to do the project he did in that tutorial, would you do what he did or would use use MVC, if you had to choose one of them?
Update: Is MVC the more appropriate way to program asp.net applications, instead of the tutorials found here:
http://www.asp.net/Learn/data-access/
Original:
I ask, because I initially learned about MVC with Java applications, then things like RoR, and Django. These other projects and companies spoke as if MVC had been around for a very long time, and from what I found out it had. Then Microsoft started putting MVC into the .net framework.
I ask because I don't know how to design things very well and thought I was doing well to emulate what's on the asp.net site with Scott Mitchell's tutorial. I thought that creating abstract layers in a BLL was the way to go until I found out about MVC and now asp.net's MVC.
I honestly don't know what the "right" way is to do things. I just create what I need, but I can't help feel like I am missing something.
Is MVC the correct way to start doing things in large projects, specifically I mean MVC and ASP.NET, but could just as well mean PHP and one of their MVC frameworks.
I'd like to settle on a standard way of doing things...for now anyway.
And, out of curiosity, why did Microsoft only now start doing MVC?
UPDATE: Is MVC better than the current tutorial set on asp.net?
I'm referring to the Scott Mitchell tutorials where he creates the BLL for abstraction. Or is that a linq question as well. I should have said that I understand the need for keeping logic and presentation separate but unsure the best way to do it. I was using the asp.net tutorials. It worked fine. Then I found out the rest of the world, as I saw it anyway, was using MVC. Then Microsoft started developing MVC, so to me the other method seems obsolete and the wrong way to do things.
No, it's not the only best way to do things.
MVC is just a design pattern. The goal of all design patterns is simplicity. So as long as it makes your design simpler, go with it. If it makes things more complex for your specific application, try a different approach.
Unfortunately, some people think if they see a pattern, they should use it. It's just not true. Design patterns don't inherently make your application better. They are not an end. They are a means to an end (which is simplicity). So you should use them only if they are worth it.
In my opinion, over-architecting things without a good reason is worse than writing code without any specific design.
EDIT: Regarding ASP.NET MVC: I have a negative personal bias toward ASP.NET Web forms. Before MVC, I did most of the dynamic aspects of advanced projects by writing custom handlers to have fine grained control over the HTML. Web Forms make Web development very easy but they have particularly a couple things that are good but sometimes are problematic. The first of which is ViewState and the second is complex WebControl architecture. Don't get me wrong. Those are signs of brilliance of ASP.NET. I haven't seen a single platform for Web development as easy as ASP.NET Web Forms and this is only because of great WebControl support which requires ViewState. However, in some projects, you want to have precise control on rendered HTML (specially when you have some client-side logic). You also want to make server side code maintainable in large projects. In those areas, ASP.NET MVC really shines. But I think ASP.NET Web Forms will remain a great technology where it's more applicable. After all, as I said regarding design patterns in general, you should carefully evaluate your design to see which one better fits your needs.
Specifically, about data access, MVC usually requires more code than Web Forms counterparts. For presenting tabular data (i.e where GridView is applicable), I think ASP.NET Web Forms is the easier way to accomplish things. However, most data driven Web apps are not just manipulating a table directly in a database. They have complex layout. StackOverflow is a great example of this. It is certainly data driven, but ASP.NET MVC better suits it.
There is no "right" way to do things without knowing what "things" are. MVC is a design pattern that solves a specific common problem - separation of presentational and domain logic. Every design pattern is a commonly accepted "good" solution to a specific problem.
Those solutions, combined with knowledge and experience are building blocks for a good design. The "right" way to do things is to study your problem domain, research on possible solutions and apply the set of solutions that work best to solve it. Making mistakes is a part of the process as well, so don't be afraid to experiment and then refactor with rigor until you reach the solution that serves you best.
MVC is the worst way to develop applications, except for all other ways that have been tried. :-)
Joking aside, MVC is one application design that encourages us not to write spaghetti code. It's a guideline that reminds us to keep business code separate from presentation code. This is very helpful as the application gets more complex.
There are other variations that achieve that same benefit, but are not strictly the same as MVC. Presentation-abstraction-control (PAC) is one example.
As for why Microsoft is so late in adopting MVC, I'm not surprised that they are. They are pretty well-known (at least in recent years) for being conservative instead of innovative. They prefer to let other smaller companies take the risks in an unproven market, then they learn from the mistakes, churn out an overengineered competitor solution, and dominate through marketing.
Example: Microsoft Internet Explorer was considered to be a latecomer to the browser market. Netscape had become very popular, leading the way in providing a platform for people to view HTML. Once the amount of HTML content on the Internet was at a useful level, Microsoft belched up their onomatopoeic "IE" product and quickly captured an overwhelming market share.
MVC is just one way of doing things. I like it because it helps to promote extensibility and is structured to allow testing and code reuse. There is no silver bullet, one true way to do everything but I use it quite often.
In regard to Microsoft, I would say that they adopted the pattern as an alternative to WebForms development for the reasons I mentioned above. I would recommend looking at Rob Conery's MVC Storefront and kind of play around with the examples to see how it works for you.
There is no "best" way to code things. It depends on the application in question; sometimes MVC is the right choice, and sometimes it's not. A good developer is able to weigh his/her options and choose the one that's best suited for a task at hand, instead of just going with the method du jour
If MVC solves the Primary Technical Imperative of managing complexity in your application then it may be a good solution, but it is by no means the only solution.
MVC is one of any number of design patterns. Whether it's the best technologically, or the simplest, or for what types of projects it's appropriate, are are all arguable (see other SO threads). In any case, few would argue against the prevailing consensus that for most cases, it's "Good Enough".
But it has the undeniable benefit that a lot of people use it, on a lot of different platforms.
So if you want to use a methodology that is likely to be around a while; or you don't want to depend on one vendor for support and extension and refinement; or you work in a group that would like to grow by hiring people from various backgrounds who will grok a shared methodology quickly; or you would like to maximize your opportunities to move on if you need to, then MVC is one of the very best ways to support those goals.
MVC being "Better" or "Worse" pattern is relative to the project.
Before I get pointed to one of those 'VS.' questions like below...
ASP.NET webforms + ASP.NET Ajax versus ASP.NET MVC and Ajax framework freedom
Should I pursue ASP.NET WebForms or ASP.NET MVC
ASP.NET MVC Web application vs ASP.NET Web Application
... please let me state that I'm not looking for a comparison.
Some of my concerns that I need answers for include:
Is the learning curve for doing crazy UIs (e.g. having UI for building a BOM tree online) steep? Lots of people posting questions seem to be having problems with some UI requirement or another which has me worried. Is the technology mature enough to handle those type of requirements?
Is there a pretty well developed community and how available is online literature? You can get tons of literature for WebForms.
Would the time to develop it be comparable or less to building a traditional enterprise WebForms site?
How long would it take to get a whole team of developers comfortable (if not enamored) with WebForms to become well versed in ASP.NET MVC?
The truth of it I think is that StackOverflow is Google-like product and ASP.NET MVC might be great for that. But I'm stuck developing software in the Your company's app category.
alt text http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
So taking a plunge could prove very costly later on if something can't be done or it has to be hacked. Hope to hear from those that have taken the plunge.
Thanks.
About 3 months ago, I was told that I needed to develop an enterprise web-app (well, a series of small web-apps actually), but that I could choose whatever technology I wanted.
Since I'm most comfortable with VS/C#/.Net, the dilemma was whether to choose ASP.NET WebForms or ASP.NET MVC2 -- Unlike you, my only background was with Windows Forms (WinForms) and a little WPF. So I had to research (and try-out) both WebForms and MVC.
Just like you, I realized that my app would be neither Google nor Apple like, but your bog standard company app with thousands of buttons and boxes, etc. WebForms seemed like it would be the fastest to deploy, but hard to test and hard to maintain on a long-term basis. MVC seemed to have a much steeper learning curve, but once established, testing and maintenance would be a breeze.
I only fiddled with WebForms for a week, so I can't really comment on it. But MVC is definitely everything I was expecting it to be.
Yes, it's a steep learning curve. Concepts that were new to me:
Model-View-Controller (MVC)
Separation of Concerns (SoC)
Model Binding
Unit Testing and Test Driven Design (TDD)
Mocking and Stubbing
Dependency Injection (DI)
The books that helped me the most were:
Pro ASP.NET MVC2 by Sanderson (MVC, Model Binding, DI, TDD)
The Art of Unit Testing by Osherove (TDD, Mocking, Stubbing, DI)
I also had to brush up on my HTML, CSS, and Javascript.
Overall, there seems to be a fair amount of ramp-up work in the beginning, but maintaining and extending the existing application has been pretty painless. Whenever I've been asked to make changes, it's been fairly easy and I've typically been able to deliver on-time or even sometimes ahead of schedule.
In an ideal world, writing an MVC app would happen with 2 people. One person writing the core code and a second person writing the UI and the Views (HTML, CSS, Javascript.) Although it's entirely possible to do it all by yourself. (which is what I'm doing right now...)
I have run into some hitches deploying in the Enterprise, though. Internally, my company is running Windows Server 2003 and IIS6. Unfortunately, we have been unable to get the app to deploy properly on IIS6 when using Virtual Pathing. (All the references to and in the CSS files are broken.) If you plan on deploying MVC, I would recommend using IIS7 or higher. MVC supposedly works on IIS6, but requires that your IT department be willing to figure out how to get it to work.
Edit: I just realized I never directly answered your questions. Here goes:
My personal experience has said, that, yes, the learning curve is steep for building good Models and UIs, but I'm not really a web-developer so I've been working with that handicap. The good news is that the MVC technology is pretty mature.
Yes, the community is pretty well developed and growing. You'll get a lot of good answers from StackOverflow as well as MS's ASP.NET MVC sub-forum.
I have no personal experience coding WebForms, but I have coded plenty of WinForms apps and I feel like it's taken me approx. 3 times longer to build this MVC app. The initial investment is a bear, but regular maintenance and improvements seem to come WAY faster, especially as the app has grown... Since you seem to have a team of programmers, it may come faster for you guys as you can probably split up the learning/workload.
Again, no prior experience with WebForms, but what I can tell you is that as I was learning ASP.NET MVC, there were times when I was struggling to understand what was going on because I had no prior ASP.NET background. (Example: Membership and Role Providers -- I had to code my own recently. Boy was that fun...) On the plus side, I didn't have any "old ways of doing things" (aka. WebForms) to unlearn either. If you have a team of folks enamored with PostBack / CodeBehind, you can bet that MVC is gonna seem awfully strange at first. But hopefully your team will see the advantages that MVC brings and embraces it fully.
Oh, and it should be noted that you can blend MVC and WebForms. It's not an all-or-nothing proposition. Although, if I were in your shoes, I'd try to embrace MVC as much as possible and only use WebForms where it clearly makes more sense.
Ok, I hope this helps... :-)
I can answer half of your question. I've just dove into MVC from a WebForms background. There is (obviously) a learning curve, but it's really not very steep. I've been able to make the transition with little effort, and I find the whole thing to be a breath of fresh air.
However, I am quite capable with front-end technologies (HTML & Javascript), and I don't like the HTML the WebForms and Microsoft ajax framework generates. If you and/or your team are like this, you will love it. However, if you are proud of the in-depth knowledge you have of the event hierarchy, or if you love the simplicity of UpdatePanels, then you'll probably bridle against the changes.
The documentation is OK, enough to get going happily, anyway. Here's a few videos to whet your appetite:
http://videos.visitmix.com/MIX09/T49F
http://videos.visitmix.com/MIX09/T50F
http://videos.visitmix.com/MIX09/T44F
Here's your documentation home:
http://www.asp.net/mvc/
For a bit more info, the first chapter of the asp.net mvc 1.0 book is online and can be downloaded for free. See ScottGu's blog here:
http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx
And, the full code for the chapter can be found here:
http://www.codeplex.com/nerddinner
Finally, in terms of development time, I think it might take a bit longer to develop apps using MVC (although I have no evidence of this), but I think supporting, maintaining, bugfixing and enhancing will take a lot less time. So, with a small up-front investment, I think you'll more than recoup that effort.
Anyway, like I said, these are my preliminary findings. I still have yet to hit a really hairy problem.
As you know its all about the people first, technology 2nd. You can simply build out a new functionality of your company app because they can co-exist, then you can answer all those questions yourself.
It's new stuff so it will of course take more time than what you're used to but heck its all fun so jump right in and start answering these questions for your own people and app.
Interesting that your question focused all on your concerns and not on any benefits. Have you asked yourself the "why" question? If you feel you can be successful with WebForms, why change to MVC? What is there in MVC that justifies the risks? If you were paying for the project, what would you do?
I'm not pitching WebForms over MVC by any means, but as an architect, you need to be able to come back very strong to the question of why you decided to go away from a very well-known quantity to a relatively new one. I think that there are many good reasons to do so, but it not my job on the line. :)