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

Question

我想弄清楚基于MVC设计的系统的类，方法，文件和文件夹的正确布局。

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

1. 我想有一个PageDAO类，将有所有数据库相关的功能（这将延长主机DAO类，这将持有通用数据库的功能选择，保存，删除等）

2. 我会单独的页面类将为此对象定义变量和非数据库相关功能

3. 我将拥有MVC本身，其中PageModel将构建页面DAO类和页面类和构建内容，然后将进行在控制器中准备一个视图

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

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

上述手段我将具有以下结构

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

• dao lib全部文件夹DAO类

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

它看起来公平吗？我只是急于不要将代码分散到太多的类中，因为它意味着更多的“包含”和更多的对象调用。但也许这是要走的路？到目前为止，我还没有使用多少MVC方法，并保持文件相当紧凑。想更多地了解最佳实践

Answer 1

这里有几件事情需要你来思考一下：

• 你Page类是标准domain object，但PageModel类是不是一个真正的模型。模型是MVC中的一个层。你所说的'PageModel'实际上是一个更高层次的对象，它具有模型层，它创建了pulic-ish接口，以便视图和控制器可以稍后与模型进行交互，而不公开任何域业务逻辑。我称这种结构为“服务”，但应该有一个更好的术语。

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

• 看起来你正在借用一些来自HMVC的概念，你应该读一点关于MVC启发的模式。

• DAO,Page' class and what you call PageModel的实例都属于模型层。

• 代码碎片并不是主要的性能问题，特别是当您通过APC启用操作码缓存时。但不成熟的优化是一个严重的问题。相反，您应该专注于让您的代码易于理解。你可以优化它的工作时间。