从 MVC 的角度来看，文件系统中最基本的实体应该放在哪里？答案

【问题标题】：In an MVC perspective, where in the file system should the very basic entities go?从 MVC 的角度来看，文件系统中最基本的实体应该放在哪里？
【发布时间】：2011-02-05 20:13:26
【问题描述】：

我说的主要是作为控制器和模型的数据容器的简单类。假设我有一个篮子模型，负责为控制器添加水果和蔬菜。但是，在页面加载期间，即从数据库或会话访问值之间并再次写回，我需要创建用于存储有关水果和蔬菜的数据的类。每个都可以包含它的数量或诸如此类的东西，并执行最基本的任务（最终它可能会扩展，但现在它的东西就像$fruits->add('apple',1)）。

这些类在文件系统的层次结构中理想地应该放在哪里？它们应该与模型紧密相连，因为其他任何地方都不需要它们。或者应该将它们重新分解成其他东西？

【问题讨论】：

标签： php model-view-controller

【解决方案1】：

您的 $fruits 在技术上也是一个模型。我不知道我是否同意能够 -> 通过容器（记录）对象添加。但是它们仍然是模型，因此它们可以进入目录或子目录。您可以执行以下操作：

models/
controllers/
views/
    <object-name>/
lib/

lib 可以包含其他库和通用类，包括基本模型/控制器/视图类。查看流行的 MVC 包，看看它们是如何做到的。

【讨论】：

然而，这些类可能有几十个，而且真的把目录弄得一团糟。
我明白了。我已经编辑了我的答案。可能是模型目录中的一个子目录。
我已经倾向于将每个模型放在自己的文件夹中并将实体保留在那里，但这会导致非常麻烦的类名 (basket_fruitHelper) 或无法自动加载。

【解决方案2】：

我认为您正在谈论一个封装数据库逻辑而不是将所述逻辑放入模型中的数据映射器。这样，模型内部唯一的持久化逻辑就是与映射器的耦合。

http://martinfowler.com/eaaCatalog/dataMapper.html

这些映射器可以放在模型所在目录中名为 Mapper 的子目录中：

模型/ 水果.php 映射器/ 水果.php

服务层

在某些情况下，如果您需要更大的灵活性，建议引入一个服务层，您可以通过该服务层将模型与映射器分离，这样只有映射器知道模型，或者甚至可能这样只有服务层知道模型和映射器是如何组合在一起的：

http://martinfowler.com/eaaCatalog/serviceLayer.html

（不要对通过以下链接讨论“Zend 框架”感到惊讶，因为它确实提出了很多关于架构的好、通用的观点，而且大多只是咆哮关于 ZendFW 出了什么问题）

http://www.angryobjects.com/2009/03/30/writing-robust-php-backends-with-zend-framework/

我会将这些服务层放在与模型相同的目录级别的文件系统中：

模型/ 水果.php 服务/ 水果.php

ORM 框架

还有可能使用现有的对象关系映射器，如 Doctrine。

http://www.doctrine-project.org/

【讨论】：

【解决方案3】：

基本上，您应该将所有数据库逻辑保留在模型中，至少这就是 MVC 的重点。

如果您真的不希望将这些方法附加到模型中，您应该创建辅助类（ Helper_Fruits ？ - /helper/fruits.php 我猜）。

【讨论】：