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

Question

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

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

1. 我会有一个PageDAO类，它将包含所有与数据库相关的函数（它将扩展主DAO类，它将保存通用数据库功能，如选择，保存，删除等）< / p>

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

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

   < / LI>

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

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

中调用

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

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

所有DAO类的

• dao lib文件夹

• 类似Page，Menu，Gallery

等类的lib文件夹

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

Answer 1

您可以考虑以下几点：

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

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

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

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

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