目前，我正在重组现有的代码库。我是php框架的新手，但我一般都知道MVC是如何工作的。
现在，有一个控制器文件，一个模型文件和30个视图文件。
每个模型应该对应一张表吗？
每个视图都应该对应一个html页面吗？
控制器怎么样？如何将这千行怪物分解为更有组织的代码。
感谢。
答案 0 :(得分：4)
每个模型应该对应一张表吗？
没有。模型通常由来自多个来源的数据构建。不要考虑将它绑定到您的物理数据库结构，即使可能最终会有很多相似之处。
每个视图都应该对应一个html页面吗？
不要陈腐，但每个视图都应对应一个视图。我不确定你的“页面”是什么意思。
也许一个例子会很有用。想象一下用户注册页面。该模型是用户，可能包含以下字段：
现在，该数据可能位于多个表中。例如：派对，人，联系人和地址。
可能会有几种观点：
通常所有这些都将由单个控制器处理，因为所有进程都是相互关联的。
答案 1 :(得分：0)
每个模型都应该对应一个逻辑数据对象 - 通常应该主要存储在一个表中（通常将外键存储到其他表中，因为模型通常需要引用其他模型）。
每个视图都应该对应于查看数据的逻辑方式（例如，在stackoverflow上，有希望看到徽章页面列表的视图，标签页面列表的视图等）。
每个控制器都应该对应一个逻辑分组的视图，这些视图分组不应该太大（太大是文件变得无法管理的行 - 如果你有30个视图，那么你希望找到一种合理的方法将它们分组为3个控制器。）
答案 2 :(得分：0)
控制器怎么样？我怎么能够 打破这千行怪物 更有组织的代码。
查看CakePHP框架以及它如何解决大型模型，控制器和众多视图的问题。我觉得很优雅。复杂模型可以具有行为。大型控制器可以分解为组件。许多视图与布局组合在一起，而公共位分为元素。它起初可能听起来很复杂和可怕，但是一旦你尝试使用它，它就会真正落到实处。
答案 3 :(得分：0)
每个型号都应该对应一个 表
它没有必要，但通常取决于业务逻辑的复杂性。
由于您正在重构现有应用程序，请考虑其他层如何使用该模型。在MVC中，模型位于依赖堆栈的底部。
视图如何访问模型？控制器将如何修改它？如何填充模型？
每个视图都应该对应一个 HTML页面？
同样，它没有必要，但它经常会。
控制器怎么样？我怎么能够 打破这千行怪物 更有组织的代码。
常见的策略是使用前端控制器模式。前端控制器处理HTTP请求，应用程序初始化和站点范围的逻辑（就像你的千行怪物目前正在做的那样） - 然后它会委托更专业的控制器。
这些专用控制器可以按照它使用的模型，站点页面结构或其他任何看似合乎逻辑的结构进行分组。然后，他们与模型交互并选择要显示的视图。
最后，像Leonid建议的那样，给框架+1。即使你最终没有使用它，也有一些很棒的控制器模式实现。
希望有所帮助。