做MVC还是不做MVC？

Question

我是MVC结构的新手，我觉得做事情很难，因为它是一种新的做事方式。有没有人有使用MVC和pages的经验。MVC的方式是现在的圣杯，还是仍然有价值做普通的面向对象的开发(甚至是过程性页面webdev)？MVC是一种时尚吗？

Answer 1

使用MVC或不使用MVC主要取决于您项目的需要。有时我有一些简单的东西，它们不需要Model，但仍然可以从控制器/视图安排中受益。在这些情况下，我可能会选择一个微框架(对于PHP来说，这将是一个柠檬汁)，甚至更少。尽管如此，我的大多数web项目都是MVC应用程序。

我在1996-1997年左右开始制作网站，所有的东西都是新的，从长远来看，什么是好的或坏的想法是没有意义的。大约在2005年，当我离开军队，回到web开发领域时，在有机设计的代码的老鼠窝中战斗并不是一件令人愉快的事情。因此，当我被介绍给Ruby on Rails和MVC的概念时，我立即意识到这是游戏规则的改变者。

随着MVC越来越多地被越来越多的web项目采用，它通过提供跨公司和项目的共同点，为下一代开发人员的生活铺平了道路，使其变得更容易和更有效率。是的，从简单的协作脚本到页面项目，MVC确实有点难以接受，但任何值得做的事情都不会那么容易，对吧？

话虽如此，如果你在一门语言中掌握了良好的MVC基础，它可以为你提供学习其他语言的心理共同点。至于MVC作为一个占主导地位的框架设计模式会持续多久，软件行业就像一片沙漠，每天的事情都在变化，伟大的想法被更好的想法所掩盖( websockets的XHR，原生音频/视频标签的嵌入式对象)，但我认为无论最终取代MVC的是什么，都会有一些相似之处，因为如果只有一小部分人理解一个想法，那么它再伟大也无关紧要。

Answer 2

MVC的利弊简明列表

Pros

• Testablily
• Separation of Concerns -促进主要components
• Helps之间的解耦您一次只关注一个任务/区域

非常适合网络和桌面设计模式、单一责任原则等

Cons

• 可能需要更多代码和工作
• 可能会降低简单页面的清晰度(在这些情况下，请尝试继续使用简单页面)
• 将需要更多学习

MVC不仅仅是一种时尚。这是一种非常实用的方法，可以将web应用程序的多个关注点划分为可管理和可重用的部分。诚然，一开始确实需要一些适应，但只要有意识地分解你的应用程序，MVC风格就会非常有价值。通常，解决方案更简洁，因为它们只需要专注于单个操作或任务。

这也不是一个新的想法。自1979年(@Sarfraz Ahmed's link)以来，它一直以这样或那样的形式出现，并已在各种web和桌面平台中使用。

如果您发现自己在使用MVC样式的实现时遇到了问题，请尝试将其分解为正在使用的各个部分或操作，以及它们相应的区域、模型视图或控制器。正如您可能预期的那样，随着时间的推移，这将变得更容易。

祝好运

Answer 3

如果我们谈到ASP.NET MVC，the framework page itself在这一点上有一个讨论：

ASP.NET MVC框架提供了以下优势：

• 通过将应用程序划分为模型、视图和控制器，可以更轻松地管理复杂性。
• 它不使用视图状态或基于服务器的表单。这使得MVC框架非常适合希望完全控制application.
• It行为的开发人员使用Front controller模式，该模式通过单个控制器处理Web应用程序请求。这使您能够设计支持丰富路由基础结构的应用程序。有关详细信息，请参阅MSDN网站上的前端控制器。
• 它为测试驱动开发(TDD)提供了更好的支持。
• 它非常适用于需要对应用程序行为进行高度控制的大型开发人员团队和网站设计人员所支持的网站应用程序。

基于Web表单的框架具有以下优点：

• 它支持通过HTTP保留状态的事件模型，这有利于业务线网络应用程序的开发。基于Web Forms的应用程序提供了数十个事件，数百个服务器控件都支持这些事件。
• 它使用页面控制器模式，将功能添加到各个页面。有关更多信息，请参见MSDN网站上的页面控制器。

MVC

• 使用视图状态或基于服务器的窗体，这可以简化状态信息的管理。
• it非常适合于希望利用大量可用于快速应用程序的组件的小型Web开发人员和设计人员。

通常不太复杂，因为组件(页面类、控件等)紧密集成，并且通常比

• 模型需要的代码更少。