MVC 中数据访问层和模型的区别

Question

我已经在几个 Web 应用程序中实现了我认为相当不错的 MVC 表示形式，但自从加入裂纹溢出之后，我发现也许我最初的定义有点简单化，因此我真的很想澄清一下Web 应用程序的数据访问层和模型或域层。

对于上下文，我目前使用数据访问对象来为该对象表示的表中的单个记录实现 CRUD 函数，以及返回一个对象的 get() 函数，该对象允许我迭代所有满足该条件的对象。 get() 函数的标准。

这些数据访问对象直接从包含我的业务逻辑的控制器脚本引用。

如果重要的话，我正在使用 PHP 和 MySQL，但对可能用其他语言编码的建议感兴趣。

更新：举一个更具体的例子，我有一个名为 user 的表（这里的约定是单数表名），其中包含电子邮件地址、活动状态、用户名、密码、他们属于哪家公司等信息这个基本对象在代码中看起来像这样：

class User implements DataAccessObject
{
     protected $user_id;
     protected $email;
     protected $username;
     protected $password;
     protected $company_id;
     protected $active // Bool that holds either a 0 or 1

     public function __construct ( $user_id ) // Uses Primary Key to know which record to construct
     {
          $sql = //Sql to get this information from the database.

          // Code necessary to assign member variables their values from the query.
     }

     public function insert(){}
     public function update(){}
     public function delete(){}
     public static function get($filters, $orderVals, $limit){}

     // An object such as user might also contain the following function definition
     public static function login($username, $password){}
}

听起来我可能已经将 DAO 层和模型层简化为一种简化的形式，将任何现实世界的类型功能（例如用户登录）与数据结合起来访问功能。

Answer 1

模型类作为现实世界实体的良好、干净、高保真模型而独立存在。 如果它是一个业务领域，它们可能是客户、计划、产品、付款等等。 您的应用程序可以使用这些类。 这个想法是，您的应用程序是现实世界中域对象处理的模型。 您的应用程序可以具有看起来像人们真正使用的动词的方法函数，并且这些方法函数的实现看起来像真实世界对象的真实描述。

重要提示：（理想情况下）这与大多数技术考虑因素无关。 它是您可以定义的领域对象的最纯粹的模型。 [是的，您确实有外键查找问题，是的，您确实必须使模型对象了解某些数据访问组件，以便模型对象可以在仅给定外键而不是实际对象的情况下找到彼此的对象。 一个好的 ORM 层可以为您处理这个导航问题。]

充满 SQL 的模型不是一个好的模型。 现实世界也并不充满 SQL。 发票是一份包含一些名称、地址、物品、发货日期以及诸如此类的内容的文档。

访问类处理持久存储。 这通常包括将模型对象映射到关系数据库表。 面向 SQL 的数据访问层将从关系数据库重建您的模型，并将您的模型保留在关系数据库中。 YAML 数据访问层将从模型中读取和写入 YAML 文件。

有时，对象关系映射 (ORM) 设计模式用于在 SQL 世界和模型之间进行清晰的分离。 有时，数据访问对象 (DAO) 会处理 SQL 和模型之间的这种分离。 ORM 或 DAO 对象可以充满 SQL。

事实上，当您更改数据库产品时，唯一的更改是 DAO 或 ORM。 该模型永远不会改变，因为它独立于 SQL、YAML、JSON、XML 或其他一些序列化技术。

如果您的 DAO 创建并保留模型对象，我认为您已经很好地实现了 MVC 的模型部分。 您可以查看 ORM 包以获取最新技术的更多想法。 我本人是 iBatis 的粉丝。

但这只是整个 MVC 世界观的 1/3。 当然，纯粹主义者会告诉您，MVC 只是桌面或只是小型谈话，或者与 MVC 的常见 Web 实现不同。

Answer 2

这只是一个更高抽象的问题。 如果您考虑要解决的某些业务问题，您需要根据该业务的概念（实体、关系、流程等）来考虑它，而不是根据数据库对象或更详细的级别来考虑。某些特定数据库系统（例如 MySQL）的内部结构。
这样，您可以根据用于实现的特定技术独立地对域（即业务及其规则）进行建模。

换句话说，当您谈论“数据访问层”时，您谈论的是表、行、数据类型，甚至是访问这些数据的方法（例如，通过使用活动记录模式），而当您谈论域时，您谈论的是谈论业务对象、业务规则和业务流程。

顺便说一句，当使用 MVC 模式时，您应该将业务逻辑封装在模型（域）级别（正如我上面所说），而不是控制器中 - 可以这么说，它们应该只是触发这些规则。