基于 MVC 的系统通用文件/文件夹结构

Question

我正在尝试为基于 MVC 设计的系统找出类、方法、文件和文件夹的正确布局。

假设我们有一个页面。 页面是一个带有标题、文本和子菜单的简单页面。它还可以包括一个画廊（这在数据库和代码中都是一个单独的对象）。

1. 我将拥有一个 PageDAO 类，该类将具有所有与数据库相关的功能（它将扩展主要的 DAO 类，将包含通用数据库功能，如选择、保存、删除等）

2. 我会有一个单独的 Page 类来定义这个对象的变量和非 db 相关函数

3. 我将拥有 MVC 本身，PageModel 将在其中构造页面 DAO 类和页面类并构建内容，然后在控制器中处理并为视图做准备

4. 画廊将在 MVC 之外的一个单独的类中定义（比如说 libs 文件夹），它永远不会用作视图（我的意思是，我永远不会调用画廊页面本身）。页面模型将创建 Gallery 类，控制器将其放置在页面视图中

5. 菜单类/功能将是更通用的功能（因为它适用于页面和类别，如果代码用于例如购物网站）并且也将在单独的区域中定义（可能是 libs 文件夹再次）。基于该功能的菜单设置将在模型中调用

以上意味着我将具有以下结构

• 基于标准 MVC 方法的模型、视图、控制器文件和文件夹

• 所有DAO类的dao lib文件夹

• 类如Page、Menu、Gallery的lib文件夹

你觉得公平吗？我只是不想将代码分散到太多的类上，因为这意味着更多的“包含”和更多的对象调用。但也许这就是要走的路？到目前为止，我还没有使用太多的 MVC 方法，并且一直在保持文件相当紧凑。想了解最佳做法

Answer 1

您可以考虑以下几点：

• 您的 Page 类是标准的 domain object，但 PageModel 类并不是真正的模型。模型是 MVC 中的一个层。你所说的'PageModel'实际上是一个带有模型层的更高级别的对象，它创建了一个公共接口，以便视图和控制器可以稍后与模型交互，而不暴露任何域业务逻辑。我将这种结构称为“服务”，但应该有更好的称呼。

• 控制器不应为视图“准备数据”。 View 不是一个哑模板（至少不应该是），它应该是一个填充对象，负责表示逻辑，可以处理多个模板

• 您似乎从 HMVC 中借用了一些概念，您应该阅读一些有关 MVC 启发的模式。

• DAO、Page' class and what you callPageModel'的实例都属于模型层。

• 代码碎片不是主要的性能问题，尤其是当您通过 APC 启用操作码缓存时。但是过早的优化是一个严重的问题。相反，您应该专注于使您的代码易于理解。您可以在它工作时进行优化。