MVC中数据访问层和模型之间的区别 [英] Difference between Data Access Layer and Model in MVC

问题描述

我已经在几个Web应用程序中实现了我认为相当不错的MVC表示形式，但是由于加入了crackoverflow，我发现也许我的初始定义有些简化，因此我真的想对数据访问层与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层和模型层混为一简，将任何实际类型的函数(例如，用户登录)与数据访问函数结合在一起.

解决方案

模型类是作为真实实体的良好，干净，高保真度的模型而单独存在的.如果是业务领域，则他们可能是客户，计划，产品，付款等等.您的应用程序可以使用这些类.这个想法是您的应用程序是领域对象的真实处理模型.您的应用程序可以具有类似于人们实际使用的动词的方法功能，并且这些方法功能的实现就像对真实对象的真实描述.

重要:这(在理想情况下)独立于大多数技术考虑因素.它是您可以定义的域对象的最纯模型. [是的，您确实有外键查找问题，是的，您的确需要使模型对象知道某些数据访问组件，以便模型对象可以在仅使用外键而不是实际对象的情况下找到彼此的对象.好的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实现不同.

I have implemented what I thought was a pretty decent representation of MVC in several web applications but since having joined crackoverflow, I'm finding that perhaps my initial definitions were a bit simplistic and thus I'd really like some clarification on the differences between the Data Access Layer and the Model or Domain Layer of a web application.

For context, I currently use data access objects that implement the CRUD functions for a single record in the table that the object represents as well as a get() function that returns an object that allows me to iterate through all of the objects that met the criteria for the get() function.

These data access objects are referenced directly from the controller scripts which contain my business logic.

If it matters, I'm working in PHP and MySQL but am interested in suggestions that might be coded in other languages.

UPDATE: For a more specific example, I have table called user (the convention here is singular table names) which holds such information as email address, active state, user name, password, which company they belong to, etc. This basic object would look like this in code:

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){}
}

It sounds like I might have bastardized the DAO Layer and Model layer into a simplified form that combines both any real-world type functions (such as login for a user) with the data access functions.

解决方案

The model classes stand alone as a good, clean, high-fidelity model of real-world entities. If it's a business domain, they might be customers, plans, products, payments, all that kind of stuff. Your application works with these classes. The idea is that your application is a model of real-world handling of the domain objects. Your application can have method functions that look like verbs people really do, and the implementation of those method functions looks like a real-world description of real-world objects.

Important: This is (ideally) independent of most technical considerations. It's the purest model of the domain objects you can define. [Yes, you do have foreign-key lookup issues, and yes, you do have to make your model objects aware of some data access components so that a model object can find each other objects given just foreign keys instead of the actual object. A good ORM layer handles this navigation issue for you.]

A model full of SQL isn't a good model. The real world isn't full of SQL, either. An invoice is a document with some names and addresses and items, and a shipping date, and a bunch of stuff like that.

The access classes handles persistent storage. This usually includes mapping your model objects to relational database tables. A SQL-oriented data access layer would reconstruct your model from a relational database and persist your model in a relational database. A YAML data access layer would read and write YAML files from your model.

Sometimes, the object-relational mapping (ORM) design pattern is used to make a clean separation between SQL's world and your model. Sometimes a Data Access Object (DAO) handles this separation between SQL and model. A ORM or DAO object can be packed full of SQL.

Indeed, when you change database products, the only change is in the DAO or ORM. The model never changes, because it is independent of SQL, YAML, JSON, XML or some other serialization technique.

If your DAO creates and persists model objects, I think you've got the model parts of MVC implemented reasonably well. You can look at ORM packages to get additional ideas of the state of the art. I'm a fan of iBatis, myself.

But's only 1/3 of the whole MVC world-view. And -- of course -- purists will tell you that MVC is only desktop or only smalltalk or different from the common web implementation of MVC.

这篇关于MVC中数据访问层和模型之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！