javascript - 为何在PHP 开发中需要使用 MVC 架构处理？
我个人觉得这种架构用起来非常的臃肿(个人感觉)，不适合开发。(不是大公司，自己个人开发)。
那种你看不到前端界面进行开发的感觉，感觉很奇怪，总觉得和前端脱了节。
所以希望有人能给出一些合理的意见，让我有理由相信这种模式能够更好的帮助我开发，谢谢！
回复内容：
我第一次接触 MVC 架构是 ThinkPhp 框架的使用。
我个人觉得这种架构用起来非常的臃肿(个人感觉)，不适合开发。(不是大公司，自己个人开发)。
那种你看不到前端界面进行开发的感觉，感觉很奇怪，总觉得和前端脱了节。
所以希望有人能给出一些合理的意见，让我有理由相信这种模式能够更好的帮助我开发，谢谢！
MVC不仅仅是一个开发模式，更是一门严肃的协作哲学，在软件开发上的典型体现。
软件开发有一句名言：“高内聚，低耦合”。在一个大型的项目中，不得不分离各个功能。这时就要求各个模块之间必须做好自己的事情，只和其他模块做必要的交互，建立必要的逻辑关系，而绝对不能深入别人的内部逻辑。
只有这样，一个完整的项目才能一块块地搭建起来。如果人人的开发都是“牵一发而动全身”的，那么项目肯定毁于各部门之间的联系、交流、推诿和扯皮当中。
“看不到前端界面进行开发的感觉，感觉很奇怪，总觉得和前端脱了节”？
按我的看法，脱了节才是对的。如果把php的后端逻辑，和html的前端代码搅成一团浆糊，那才是真正的噩梦。
这就是框架的好处：框架从结构上强制要求业务逻辑的分离。这样对个人容易板正习惯，对群体容易协同工作。
所以学习框架不仅是应用性的，更是一个发展性的习惯。因为如果真的很严肃把对待php开发当作事业，那么融入群体开发是早晚的事。这样，就算没有成型的框架，也会有一个群体内部协调好的一个业务分离的结构。如果不能适应、难以遵守恐怕就麻烦了。
前端看不到？好整，我宁可先摆个最丑陋（甚至没有CSS）的前端，调试稳定了，然后再到网上去扒样式。
MVC架构，到头来多半是个观念，其实也未必需要用成型框架来实现。你可以先考虑学一套模板引擎，彻底抛开PHP单纯做前台的HTML/CSS（V）；然后把数据库的读写操作集中成块（M）；最后编制一套网址结构，用来调用模板或调用后台操作（C），其实这样MVC结构，也就自然做出来了。
MVC 不光是 PHP 的概念，是 PHP 从其他语言借鉴过来的，现在差不多所有 PHP 框架都有某种形式的 MVC 思想。
MVC 的核心是将 数据操作(Model), 前端页面(View), 业务逻辑(Controller) 分离，每个部分可以单独工作，替换。
比如，前端页面和业务逻辑分离，可以直接把前端页面交给前端设计师来修改，前端设计师无需了解 PHP 和业务逻辑。这不是脱节，这是分工。
比如当从一种数据源(数据库)更换到另外一种数据源时，只需修改 Model 即可，前端和业务逻辑都无需修改。
另外，你不觉得把这三部分分开，代码会更加清晰么。想象一下在 PHP 里面拼 HTML, 以及在 HTML 里反复开关 PHP 标记，这是有多么蛋疼。
MVC 算是目前的趋势吧，个人以为只要一个应用有一个以上的页面，都有采用 MVC 模式的必要。
至于你说比较臃肿...这可能是 ThinkPHP 比较臃肿吧，MVC 只是思想，也是有很多轻量级的 MVC 框架的。
楼上对MVC做了很多解释，不想多说了，说一下你困惑的原因吧：
- 你做得项目规模太小，MVC无法发挥优势。因此，如果确实是小项目，没必要一定要用MVC模式开发，自己怎么快速方便怎么来就行，或者选一些轻量级的框架
- 你是个人开发而不是团队开发，MVC仍然无法发挥优势。当你经历了多人协作开发一个项目之后，你自然就明白了，有框架的既有规则在那里规范着，是多么重要，多么方便的事情
- 你做的可能基本是一次性开发，而不是持续迭代，或者后期维护。当一个大型项目，需要不断扩展功能，修改数据层、逻辑层、表现层的东西的时候，你也就会明白MVC模式带来的优越性了
总之，合适的场景下使用合适的工具，不要拘泥。同时，也不要觉得目前一些已经被普遍证明的设计模式没什么用处，虽然你现在可能用不上，但是仍然应该多使用，多研究，多积累，总有一天会大彻大悟的。
看来楼主应该是刚工作不久或是学生吧？
你有这样的感觉因为你在做的是“个人开发”，如果你跟我一样苦逼的面对着源代码就上百MB的操蛋项目时就不会有这样的疑问了
PHP本来就是解释型语言，其实没必要过分强调MVC。
不过随着团队发展，根据分工进行必要的业务逻辑分割还是必要的。
从我个人学习的经历来看，很多一些目前看起来觉得繁琐的东西，其实都是有一定用处的，只是这个适用场景目前还没有遇到，或者没有去深入挖掘，体会不到这方面的好处。
软件开发到了一定的规模，就越加强调分层的概念，把不同的功能进行隔离，也就是解耦，在这个过程中，MVC就是一种比较典型的宏观意义上的分层的概念，把最基本的三层概念进行区分。
其实thinkphp还算不上臃肿的框架，也是比较轻量级的，建议题主在学习的过程中，不要去特别在意这些概念，一步一步学下去，即使某一种思想是错的，对自己也是一种补充。用完框架，可以顺势去看一下框架的源代码，对自己也是一种提升
规模问题吧？做的东西太小确实没什么用还不如直接写来得好，但是综合考虑扩展什么的话，优势就逐渐体现出来了。
我这里说一下上面几位没有说清楚的：开发在一个产品或者是项目中只是占了一部分。 如果你仅仅只是为了开发能够舒服，并且你是个体开发者，那么也许MVC对你来说意义不算太大。 但是对于团队开发以及后期维护来说，MVC这个概念你是绝对不能忽视的。 试想一下，一个七八个人的团队，开发一个业务逻辑十分多的产品，而对于业务、视图以及数据你不能很好地分离，甚至七八个人需要同时操作一个地方。效率会高么？ 这仅仅还只是开发层面上的。 要是后期维护呢？对于一些线上的产品，开发周期比维护周期可能要短得多。要是不能做好模块化管理，后期的维护将是一件十分蛋疼的事情。 你觉得对么？
项目你已经开发好了，但是客户突然要求你能做到多个前端模板，并且可以随意切换，如果你用html混杂模式，是不是要哭了？不用模板分离，业务分离，如果你的代码交给别人去看，那人家简直要疯掉
ThinkPHP 算不上臃肿吧，你是没见过YII Laravel Zend ……
thinkphp就是语法太奇葩了，学习成本有点高，可以看下corephp，非常简单模板语法几乎不用学习，一两分钟就能学会了
上一篇： mysql中的日志（一）_MySQL