我正试图为基于MVC设计的系统找出类、方法、文件和文件夹的正确布局。
假设我们有一个页面Page是一个包含标题、文本和子菜单的简单页面。它还可以包括一个库（在数据库和代码中都是一个单独的对象）。
-
我会有一个
PageDAO类，它将具有所有与数据库相关的功能（它将扩展主DAO类，该类将具有选择、保存、删除等通用数据库功能） -
我会有一个单独的Page类，它将为这个对象定义变量和非数据库相关的函数
-
我将拥有MVC本身，其中
PageModel将构建页面DAO类和页面类，并构建内容，然后在控制器中进行处理，并为视图做好准备 -
Gallery将被定义在MVC之外的一个单独的类中（比如说libs文件夹），它永远不会被用作视图（我的意思是，我永远不会调用Gallery页面本身）。页面模型将创建Gallery类，控制器将其放置在页面视图中
-
菜单类/函数将是更通用的函数（因为如果代码用于购物网站，它将同时适用于页面和类别），也将在单独的区域中定义（也可以是libs文件夹）。基于该功能的菜单设置将在模型中调用
以上意味着我将拥有以下结构
-
基于标准MVC方法的模型、视图、控制器文件和文件夹
-
所有
DAO类的dao lib文件夹 -
类（如
Page、Menu、Gallery）的lib文件夹
你觉得公平吗？我只是不想把代码分散在太多的类上，因为这意味着更多的"include"和更多的对象调用。但也许这就是要走的路？到目前为止，我还没有使用太多MVC方法，并且一直在压缩文件。想了解的最佳实践
以下是一些需要考虑的事项：
-
您的
Page类是一个标准的域对象，但PageModel类实际上并不是一个模型。模型是MVC中的一层。您所称的"页面模型"实际上是模型层中的更高级别对象，它创建了pulic ish接口，以便视图和控制器稍后可以与模型交互，而不会暴露任何域业务逻辑。我把这种结构称为"服务"，但应该有一个更好的术语来形容它 -
控制器不应为视图"准备数据"。视图不是一个愚蠢的模板（或者至少，它不应该是），它应该是一个填充的对象，负责表示逻辑，可以处理多个模板
-
看起来你是在借用HMVC的一些概念，你应该读一点关于MVC启发的模式。
-
DAO、Page' class and what you callPageModel的实例都属于模型层。 -
代码碎片不是主要的性能问题，尤其是当您通过APC启用操作码缓存时。但是过早的优化是一个严重的问题。相反，您应该专注于使代码易于理解。你可以在它工作时进行优化。