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

Question

我在多个Web应用程序中实现了我认为相当不错的MVC模式，但自从加入crackoverflow以来，我发现我的最初定义可能有点过于简单化了，因此我真的想要一些关于数据访问层和模型或领域层之间差异的澄清。

为了背景信息，我目前使用实现单个记录的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层和Model层混合成了一个简化的形式，将真实世界类型函数（例如用户登录）与数据访问函数结合在一起。

- gabriel1836

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世界观的三分之一。当然，纯粹主义者会告诉您，MVC仅适用于桌面或仅适用于Smalltalk，或者与MVC的常见Web实现不同。

- S.Lott

Answer 2

这只是更高抽象程度的问题。如果你正在考虑要解决的某个业务问题，你希望从该业务的概念（实体、关系、过程等）角度来思考，而不是从数据库对象或更详细的层次上来看，比如特定数据库系统（例如MySQL）的内部。

这样，您可以独立于用于实现的特定技术来对领域（即业务及其规则）进行建模。

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

顺便说一下，使用MVC模式时，应该将业务逻辑封装在您的模型（领域）层中（如上所述），而不是在控制器中 - 它们只应该触发那些规则，就这么说吧。

- Milan