有没有理由在没有MVC的情况下按程序编写一个相当大的、以数据库为中心的PHP应用程序？

很抱歉，我提出了一个相当主观的问题，但我希望从一个比我更有经验的人那里得到关于这个问题的意见

我对ajax驱动的PHP应用程序非常熟悉，虽然在客户端标记和行为之间有很好的分离，但我的PHP正在慢慢变得有点混乱。到目前为止，我做得还不错，将它分解成多个部分，并以一种不会有太多重复的方式进行结构化，但我确实开始看到，如果有足够的代码，这会成为一种负担。所以我一直在阅读OOP和MVC，现在我正试图决定是否值得为CodeIgniter或Kohana进行重构。直觉上，我觉得这将是一个比它的价值更多的工作，但我知道我可能会唱一个不同的调子在一段时间

根据您的经验，现在按程序编写一个严肃的应用程序被认为是绝对不成熟的，还是有某些类型的应用程序更适合于程序化/结构化编程。

MVC和OOP只是“方法”，等等。是的，它们很棒，有助于代码的良好结构，并且被大量使用，但它们不是开发应用程序的唯一方法

例如，Drupal没有使用任何类型的面向对象代码：它都是过程性的。。。这是一个大的应用程序，有很多成功，被很多人使用，甚至在大型网站上，而且很多人已经为它开发了很多模块。。。即使它几乎不使用任何类/对象

---

一、 就个人而言，对于几乎任何类型的新应用程序，都会使用MVC和/或OOP；只是因为我知道这些，它们是有用的——但在开发一个伟大的应用程序时，它们不是必需的：它们有帮助，但如果你在编程时不表现出行为，你仍然可以得到一些糟糕的代码。^^ ^

我记不起上一次我看到任何完全属于一种编程范式的大型、严肃的应用程序是什么时候了，哎呀。（也就是说，如果“面向对象”是一个统一的概念。）

---

如果一个程序没有使用OOP，我一点也不担心，但是如果它只使用一个范例，我会有点担心。（如果它根本不使用函数式编程，我可能会更加怀疑。）没有一项大型任务是完全同质的，因此，如果您试图对整个程序使用一种范式，那么它可能在某些领域非常适合，而在其他领域则不适合。

谢谢。我想这正是我需要听到的，在我把一切都搞砸之前，我试图让一切变得更好。在我开始的下一个项目中，我肯定会给OOP一个机会，但我认为我已经用一种不同的方法做了很多事情，如果把它全部拆开，然后在此时重新开始，那将适得其反。@RageZ:谢谢@格雷格：如果你有一个庞大的现有代码库，不重新破解它来改进可能会更好——至少在短期内是这样（而且它不会阻止你在需要的时候在应用程序的某些新部分使用OOP），老实说，我不是一个很好的程序员，但我想我学得很快，我会努力吸收我遇到的任何聪明的方法。到目前为止，这是一种“即兴编程”。：）我想这是一种很好的表达方式，我不知道我到底在做什么——但当我通过尝试一个错误找出什么在哪里和什么时候最有效时，它慢慢成为焦点，我只需要保持一致性和组织性。我在学习。所以我帮了很多忙。