个人附录：我已将 ASP.NET 和 ASP.NET MVC 用于 Web 应用程序。 MVC 更好。不是更快，而是更好。它让网络开发对我来说再次变得“有趣”。
There really are no good answers.
I'd be very surprised if you could recreate a non-trivial business application in a new format (web) in any 'short' amount of time (unless you measure 'short' to be 6 months).
ASP.NET MVC provides (hands down) the most convention available with any beginning web project.
ASP.NET lets you drag-and-drop to get things working, but it breaks maintenance horribly for non-trivial applications.
If it were me, I'd do three things:
Ask my boss if he wants me to recreate an entire business application across a completely different platform.
Tell him he can either have it more quickly now (ASP.NET), or more quickly later (ASP.NET MVC).
Let him make the call.
Personal Addendum: I've used both ASP.NET and ASP.NET MVC for web applications. MVC is just better. Not faster, but better. It made web development 'fun' again for me.
You'll be writing much more infrastructure code than the RAD Webforms alternative of dragging a datagrid and a datasource onto a .aspx page. I love MVC but if you're under the gun go with Webforms. MVC can be faster, but only if you have infrastructure pre-built.
MVC 2 alleviates some of this by including Model based HTML helpers like Model.EditorFor() but it's not good enough yet. No quick grid code. Paging? You're rolling your own pager. Ajax? Write your own JQuery.
Sure, there are 3rd party and open source libraries available for all this stuff but in my experience smushing them all together and making sure they play nice is also time consuming.
我发现，随着网络应用程序的复杂性线性增加，网络表单应用程序的复杂性呈指数级增加。一旦开始编写自己的服务器控件（不是用户控件，因为它们仍然相对简单）（这对于更复杂的 UI 来说可能是必需的），您需要深入了解整个页面生命周期、视图状态如何工作以及其他框架从您那里抽象出的 Web 表单的模糊部分。
MVC 虽然需要您很好地了解 HTML，但它在复杂性的尾部表现出色。无论应用程序多么复杂，您仍然需要处理控制器中的 POCO 和方法。一旦克服了最初的障碍，一切就会一帆风顺。开发难度随着网站难度的增加而增加。
个人经验：我将一个使用自定义服务器控件的相对复杂的网站转换为 ASP.NET MVC，并将代码库削减了一半。我还大大降低了代码的复杂性。
我唯一需要注意的是，使用 ASP.NET AJAX 更容易实现 ajax。因此，如果您要开发一个严重依赖 ajax 的 Web 应用程序，那么 Webforms 可能会胜过 MVC。
从 ASP.NET 迁移到 MVC 并不总是最简单的。您必须从基于代码隐藏的应用程序迁移到控制器不知道您的 UI 的应用程序。此外，MVC 严重依赖 URL 来确定用户的意图，而 ASP.NET 则依赖事件处理程序。
就我个人而言，如果我觉得一个应用程序注定是 MVC，我就不会浪费时间在 ASP.NET 中开发它。但后来，我受益匪浅，克服了最初的学习曲线。恕我直言，这并不是那么糟糕。我在学习 ASP.NET 阻止我学习的所有 HTML 和 HTML 表单时遇到了更多困难。
Simple web application + tight schedule = ASP.NET webforms.
Complex web application + tight schedule = ASP.NET MVC.
I've found that as the complexity of a web app increases linearly the complexity of a webforms app increases exponentially. Once you start writing your own server controls (NOT user controls, as those are still relatively simple), which can be necessary for more complex UI, you need to have an intimate knowledge of the whole page lifecycle, how the viewstate works, and other obscure parts of webforms that the framework abstracts from you.
MVC, while it requires you know HTML well, does great on the tail end of complexity. No matter how complex the application is, you're still dealing with POCOs and methods in your controller. Once you get over the initial hurdles, its smooth sailing. Development difficulty increases at the same pace as website difficulty.
Personal experience: I converted a relatively complex website using custom server controls to ASP.NET MVC and cut the codebase in half. I also drastically reduced the complexity of the code as well.
The only caveat I have is that ajax is easier to do using ASP.NET AJAX. So if you're going to develop a web app that relies heavily on ajax then webforms may just beat MVC.
Migrating from ASP.NET to MVC isn't always the easiest. You have to move from a codebehind-based application to one where your controllers are unaware of your UI. Also, MVC relies heavily on the URL to determine the intent of the user, whereas ASP.NET relies on event handlers.
Personally, if I felt an application was destined to be MVC, I wouldn't waste time developing it in ASP.NET. But then, I've had the benefit of getting past the initial learning curve. Which wasn't all that bad IMHO. I had more trouble learning all the HTML and HTML forms that ASP.NET kept me from learning.
With this deadline i think it's more convenient to use the ASP.Net Webform. After this first phase with more time/budget you can start to develop new parts of your application using the MVC since they can coexist.
Also be aware of the Ajax and grid code. In MVC they usually take longer to develop but also at least for me they appear to be more robust because you really have to know what you're doing.
This question is from 2009, would be nice if the author give some feedback of his decision.
You can also look the Entity Framework to bind to your database, this will create your models to be used with MVC. But Like jfar said, under short deathline pressure, go for what you know best!
From experience I vouch for it - it's how I program, it works regardless of technology.
In short: do what your gut-feel tells you (code something), modify as you find errors/omissions, and when it works, you're done (but for the documentation).
Both frameworks contribute enough in delivering a solution, but WebForms automate some of tasks involved in UI functionality, like data paging, sorting, state persistence or custom data persistence and more, BUT... if you really sit down and say, ok what do i need to do? ... design, navigate, modelize, present and then figure out how to show layout, how to connect to data, how to bring data, how to bind them with UI, how to paginate, sort and finally edit, really put your mind down and compare techinques in each framework that accomplishes all that, you will know that MVC is more natural and team oriented. You need tools like EF Code First, a CSS framework like Bootstrap and jQuery, apply techniques like IoC, SoC, Layering etc and use for example Automapper for doing the boring stuf, but no matter how many things you will have to consider, it will always be match more easy, natural and direct than having to know all the various configuration of the numerous controls and managers that WebForms require. Except if your project is an ERP with CMS capabilities where ... you know :-) Anyway, modern skils require to adapt in today's trends and MVC is just a good host to help you use them without suprises. I ve written tons of WebForms code but i am not touching it again. So, final point is that in 2014 with all those tools and frameworks out there, MVC is not slower but rather the opposite, but requires an initial, small to me, efford to gather some resources and lock a few methodologies.
发布评论
评论（10）
确实没有好的答案。
如果您可以在任何“短”时间内（除非您将“短”测量为 6 个月）以新格式（Web）重新创建一个重要的业务应用程序，我会感到非常惊讶。
ASP.NET MVC 提供（毫无疑问）任何初始 Web 项目可用的最常用约定。
ASP.NET 允许您通过拖放操作来使工作正常运行，但它严重破坏了重要应用程序的维护工作。
如果是我，我会做三件事：
询问我的老板是否希望我在完全不同的平台上重新创建整个业务应用程序。
告诉他他可以现在更快地获得它 (ASP.NET)，或者稍后更快地获得它 (ASP.NET MVC)。
让他打电话。
个人附录：我已将 ASP.NET 和 ASP.NET MVC 用于 Web 应用程序。 MVC 更好。不是更快，而是更好。它让网络开发对我来说再次变得“有趣”。
There really are no good answers.
I'd be very surprised if you could recreate a non-trivial business application in a new format (web) in any 'short' amount of time (unless you measure 'short' to be 6 months).
ASP.NET MVC provides (hands down) the most convention available with any beginning web project.
ASP.NET lets you drag-and-drop to get things working, but it breaks maintenance horribly for non-trivial applications.
If it were me, I'd do three things:
Ask my boss if he wants me to recreate an entire business application across a completely different platform.
Tell him he can either have it more quickly now (ASP.NET), or more quickly later (ASP.NET MVC).
Let him make the call.
Personal Addendum: I've used both ASP.NET and ASP.NET MVC for web applications. MVC is just better. Not faster, but better. It made web development 'fun' again for me.
MVC 并不是真正的 RAD 开发框架。
与将数据网格和数据源拖到 .aspx 页面上的 RAD Webforms 替代方案相比，您将编写更多的基础结构代码。我喜欢 MVC，但如果您处于困境，请选择 Webforms。 MVC 可以更快，但前提是您已经预先构建了基础架构。
MVC 2 通过包含基于模型的 HTML 帮助程序（如 Model.EditorFor()）来缓解部分问题，但它还不够好。没有快速网格代码。寻呼？您正在滚动自己的寻呼机。阿贾克斯？编写您自己的 JQuery。
当然，有第 3 方和开源库可用于所有这些内容，但根据我的经验，将它们全部混合在一起并确保它们运行良好也很耗时。
MVC isn't really a RAD development framework.
You'll be writing much more infrastructure code than the RAD Webforms alternative of dragging a datagrid and a datasource onto a .aspx page. I love MVC but if you're under the gun go with Webforms. MVC can be faster, but only if you have infrastructure pre-built.
MVC 2 alleviates some of this by including Model based HTML helpers like
Model.EditorFor()but it's not good enough yet. No quick grid code. Paging? You're rolling your own pager. Ajax? Write your own JQuery.Sure, there are 3rd party and open source libraries available for all this stuff but in my experience smushing them all together and making sure they play nice is also time consuming.
简单的 Web 应用程序 + 紧张的日程 = ASP.NET Web 表单。
复杂的 Web 应用程序 + 紧张的日程 = ASP.NET MVC。
我发现，随着网络应用程序的复杂性线性增加，网络表单应用程序的复杂性呈指数级增加。一旦开始编写自己的服务器控件（不是用户控件，因为它们仍然相对简单）（这对于更复杂的 UI 来说可能是必需的），您需要深入了解整个页面生命周期、视图状态如何工作以及其他框架从您那里抽象出的 Web 表单的模糊部分。
MVC 虽然需要您很好地了解 HTML，但它在复杂性的尾部表现出色。无论应用程序多么复杂，您仍然需要处理控制器中的 POCO 和方法。一旦克服了最初的障碍，一切就会一帆风顺。开发难度随着网站难度的增加而增加。
个人经验：我将一个使用自定义服务器控件的相对复杂的网站转换为 ASP.NET MVC，并将代码库削减了一半。我还大大降低了代码的复杂性。
我唯一需要注意的是，使用 ASP.NET AJAX 更容易实现 ajax。因此，如果您要开发一个严重依赖 ajax 的 Web 应用程序，那么 Webforms 可能会胜过 MVC。
从 ASP.NET 迁移到 MVC 并不总是最简单的。您必须从基于代码隐藏的应用程序迁移到控制器不知道您的 UI 的应用程序。此外，MVC 严重依赖 URL 来确定用户的意图，而 ASP.NET 则依赖事件处理程序。
就我个人而言，如果我觉得一个应用程序注定是 MVC，我就不会浪费时间在 ASP.NET 中开发它。但后来，我受益匪浅，克服了最初的学习曲线。恕我直言，这并不是那么糟糕。我在学习 ASP.NET 阻止我学习的所有 HTML 和 HTML 表单时遇到了更多困难。
Simple web application + tight schedule = ASP.NET webforms.
Complex web application + tight schedule = ASP.NET MVC.
I've found that as the complexity of a web app increases linearly the complexity of a webforms app increases exponentially. Once you start writing your own server controls (NOT user controls, as those are still relatively simple), which can be necessary for more complex UI, you need to have an intimate knowledge of the whole page lifecycle, how the viewstate works, and other obscure parts of webforms that the framework abstracts from you.
MVC, while it requires you know HTML well, does great on the tail end of complexity. No matter how complex the application is, you're still dealing with POCOs and methods in your controller. Once you get over the initial hurdles, its smooth sailing. Development difficulty increases at the same pace as website difficulty.
Personal experience: I converted a relatively complex website using custom server controls to ASP.NET MVC and cut the codebase in half. I also drastically reduced the complexity of the code as well.
The only caveat I have is that ajax is easier to do using ASP.NET AJAX. So if you're going to develop a web app that relies heavily on ajax then webforms may just beat MVC.
Migrating from ASP.NET to MVC isn't always the easiest. You have to move from a codebehind-based application to one where your controllers are unaware of your UI. Also, MVC relies heavily on the URL to determine the intent of the user, whereas ASP.NET relies on event handlers.
Personally, if I felt an application was destined to be MVC, I wouldn't waste time developing it in ASP.NET. But then, I've had the benefit of getting past the initial learning curve. Which wasn't all that bad IMHO. I had more trouble learning all the HTML and HTML forms that ASP.NET kept me from learning.
到了这个截止日期，我认为使用 ASP.Net Webform 会更方便。在第一阶段之后，有了更多的时间/预算，您可以开始使用 MVC 开发应用程序的新部分，因为它们可以共存。
还要注意 Ajax 和网格代码。在 MVC 中，它们通常需要更长的时间来开发，但至少对我来说，它们似乎更强大，因为您确实必须知道自己在做什么。
这个问题是 2009 年提出的，如果作者能对其决定提供一些反馈，那就太好了。
编辑：如果您仍然需要使用 asp 的 RAD，请查看 http://mvcscaffolding.codeplex.com/ .net MVC。
With this deadline i think it's more convenient to use the ASP.Net Webform. After this first phase with more time/budget you can start to develop new parts of your application using the MVC since they can coexist.
Also be aware of the Ajax and grid code. In MVC they usually take longer to develop but also at least for me they appear to be more robust because you really have to know what you're doing.
This question is from 2009, would be nice if the author give some feedback of his decision.
EDIT: Take a look into http://mvcscaffolding.codeplex.com/ if you still need a RAD using asp.net MVC.
一旦您开始使用 MVC，速度会很快，但是需要一段时间 a) 学习和 b) 构建一套有用的代码。
如果您的用户界面不复杂，那么设置快速数据输入界面可能会非常容易。
如果您的 UI 确实非常简单，您可能需要查看 ASP.net 动态数据。
Once you get running with MVC, it's pretty quick, but it takes a while a) to learn and b) to build up a suite of useful bits of code.
If your UI is not going to be complicated, it can be very easy to set up a quick data entry interface.
If your UI is to be really, really simple, you might like to look at ASP.net dynamic data.
您还可以查看实体框架以绑定到数据库，这将创建与 MVC 一起使用的模型。但就像 jfar 所说，在短暂的死亡压力下，去做你最了解的事情！
You can also look the Entity Framework to bind to your database, this will create your models to be used with MVC. But Like jfar said, under short deathline pressure, go for what you know best!
ASP.Net MVC 很好，但是……
如果您之前没有使用 ASP.Net MVC 开发过系统，那么在截止日期很短的项目上使用它是有风险的。
如果您的应用程序是“简单”CRUD 应用程序，那么我会使用动态数据： http://www.asp .net/dynamicdata/
（Paddy 刚刚超越了我）
如果您的系统真的很大，您可以考虑 SharePoint Access Services http://blogs.msdn.com/access/archive/2009/10/21/net-developer-blogs-about-access-2010.aspx
ASP.Net MVC is good, but ....
If you haven't developed a system using ASP.Net MVC before, then using it on a project with a short deadline is a risk.
If your application is a "simple" CRUD application then I would go with Dynamic Data: http://www.asp.net/dynamicdata/
(Paddy just beat me to that one)
If your system is really big you could consider SharePoint Access Services http://blogs.msdn.com/access/archive/2009/10/21/net-developer-blogs-about-access-2010.aspx
进化软件开发
根据我的经验，我保证 - 这就是我编程的方式，无论如何它都能工作的技术。
简而言之：按照你的直觉告诉你的去做（编码一些东西），在发现错误/遗漏时进行修改，当它起作用时，你就完成了（但对于文档）。
Evolutionary Software Development
From experience I vouch for it - it's how I program, it works regardless of technology.
In short: do what your gut-feel tells you (code something), modify as you find errors/omissions, and when it works, you're done (but for the documentation).
另一种选择是使用 Alpha Five v10——
它最近获得了 Infoworld 的好评
查看http://blog.alphasoftware.com/search/label/Press%20coverage< /a>
Another option is to use Alpha Five v10 --
It recently received a thumbs up from Infoworld
check out http://blog.alphasoftware.com/search/label/Press%20coverage
这两个框架在交付解决方案方面都做出了足够的贡献，但是 WebForms 自动化了 UI 功能中涉及的一些任务，例如数据分页、排序、状态持久性或自定义数据持久性等等，但是...如果您真的坐下来说，好吧，该怎么办我需要做什么？ ...设计、导航、建模、呈现，然后弄清楚如何显示布局、如何连接到数据、如何引入数据、如何将它们与 UI 绑定、如何分页、排序和最终编辑，真正用心思考仔细比较一下每个框架中实现这一切的技术，你会发现MVC更加自然和面向团队。您需要 EF Code First 等工具、Bootstrap 和 jQuery 等 CSS 框架，应用 IoC、SoC、分层等技术，并使用 Automapper 等工具来完成无聊的工作，但无论您需要考虑多少事情，它都会与必须了解 WebForms 所需的众多控件和管理器的所有各种配置相比，匹配总是更容易、自然和直接。除非您的项目是具有 CMS 功能的 ERP，...您知道:-)
不管怎样，现代技能需要适应当今的趋势，而 MVC 只是一个很好的宿主，可以帮助您毫无意外地使用它们。
我已经编写了大量的 WebForms 代码，但我不会再碰它了。
所以，最后一点是，在 2014 年，有了所有这些工具和框架，MVC 并没有变慢，而是相反，但需要一个初始的、对我来说很小的努力来收集一些资源并锁定一些方法。
Both frameworks contribute enough in delivering a solution, but WebForms automate some of tasks involved in UI functionality, like data paging, sorting, state persistence or custom data persistence and more, BUT... if you really sit down and say, ok what do i need to do? ... design, navigate, modelize, present and then figure out how to show layout, how to connect to data, how to bring data, how to bind them with UI, how to paginate, sort and finally edit, really put your mind down and compare techinques in each framework that accomplishes all that, you will know that MVC is more natural and team oriented. You need tools like EF Code First, a CSS framework like Bootstrap and jQuery, apply techniques like IoC, SoC, Layering etc and use for example Automapper for doing the boring stuf, but no matter how many things you will have to consider, it will always be match more easy, natural and direct than having to know all the various configuration of the numerous controls and managers that WebForms require. Except if your project is an ERP with CMS capabilities where ... you know :-)
Anyway, modern skils require to adapt in today's trends and MVC is just a good host to help you use them without suprises.
I ve written tons of WebForms code but i am not touching it again.
So, final point is that in 2014 with all those tools and frameworks out there, MVC is not slower but rather the opposite, but requires an initial, small to me, efford to gather some resources and lock a few methodologies.