在同一组产品中混合使用ASP.NET MVC开发和ASP.NET Web窗体开发是否明智?

问题1:如果你没有从中受益,它是否值得?如果有效,为什么要重写它?你在单元测试你的web表单应用程序时有困难吗?如果是这样的话,那么MVC可能就是解决问题的方法。但是,如果这是一个任务关键型应用程序,而不是仅仅为了重写而重写它,那么这似乎有点违反直觉。

问题2:如果你需要MVC程序员,那肯定是个好主意。然而,你的雇佣决定应该基于他们对编程的总体了解,而不是他们所知道的周发展框架的任何风格。

关于问题2,我建议提前告知他们(如果有的话)他们使用MVC的时间。我遇到过一些MVC开发人员,他们讨厌回到WebForms的想法,这对他们来说是一个破坏协议的因素。

就他们的技能而言,MVC开发人员倾向于了解(并且感到舒适)原始Web开发(HTTP/HTML/State-less),并且这些技能即使在您执行WebForms时也很方便。

在您开始开发新的应用程序之前,听起来您根本不需要MVC。

问题1:重新开发所有东西是一个非常糟糕的主意。如果还没坏,就别修了。除非你想赔钱…或者是你的工作。

问题2:除非你需要。除非你正在开发能从MVC中获益的新应用程序,否则你不会这么做。

附录:雇佣MVC开发者有几个原因:

为了将来证明你的生意。也许有一天你需要团队中的这些技能。然而,随着需求的增加,猎头可能会更便宜。或者,在为初级web表单开发人员提供指导的同时,提供在MVC中培训的机会,从而提升团队的士气。

为了将来证明你的简历。如果你领导了一个MVC开发团队,你的工作前景将会更加光明。但是,如果你的老板亏了钱,你就会被解雇,这将被记录在案。

c.您可以将MVC与普通香草ASP.NET混合和匹配。所以当应用程序中出现新的需求时,您可以在MVC中构建它们。然而,如果新来的男孩得到了所有有趣的东西,而且他们得到了渣滓,那么你的核心团队的士气会是怎样的呢?