DAL,DTO和DAO在3层架构风格(包括MVC)之间有什么区别

时间:2016-06-05 17:47:35

标签: model-view-controller orm dao data-access-layer dto

最近我学习了ORM(对象关系映射)和3层架构风格(演示,业务和数据持久性)。 如果我理解正确,我可以将数据持久层分成DTO和DAO层。

我想了解,以下部分如何在数据持久层中协同工作。

  • DAL(数据访问层)
  • DTO(数据传输对象)
  • DAO(数据访问对象)

最重要的是我了解到了

  

在较大的应用程序中,MVC只是N层的表示层   架构。

我真的很困惑,例如在3层架构风格中它是如何可能的,其中MVC只是一个表示层,而DTO,DAO,DAL只是数据持久层的一部分。我完全迷失了。

如果有人告诉我它是如何一起工作的真相,我会很高兴。

请不要关闭这个问题,因为有很多不同的表达方式,我在任何地方都看到这些东西基本上都是在大型应用程序中彼此相关,我无法想象它是如何工作的。

我感谢任何回答!

2 个答案:

答案 0 :(得分:13)

让我们从每个目的开始: -

<强> DTO

数据传输对象。这些通常用于将数据从控制器传输到客户端(JS)。 POCO / POJO也被少数用于实际保存从数据库中检索的数据。

<强> DAO

数据访问对象是用于实现DAL的设计模式之一。这将在数​​据库上构建和执行查询,并使用各种其他模式将结果映射到POCO / POJO,包括“查询对象”,“数据映射器”和“数据映射器”。使用&#39;存储库&#39;可以进一步扩展DAO层。图案。

<强> DAL

数据访问层使用DAO / Repository / POCO等抽象您的数据库活动.ORM帮助您构建DAL,但也可以在不使用它们的情况下实现。

<强> MVC

模型视图控件是一种模式,用于将视图(表示)与业务逻辑分开。对于MVC,DAL是否实现并不重要。如果没有实现DAL,数据库逻辑只会进入你的模型,这不是一个好方法。

  

在较大的应用程序中,MVC只是N层的表示层   架构。

模型消耗了大部分业务逻辑,如上所述。在N层应用程序中,如果业务逻辑完全分离以便跨应用程序/平台重新使用,那么MVC中的模型称为贫血模型。如果BI不需要在您的应用程序中以该比例重复使用,则可以使用Model来保存它。没有混乱,对吗?

  

如果有人告诉我它是如何运作的真相,我会很高兴的   在一起。

所有MV *模式仅定义了想法/概念;他们没有定义实现。 MV *模式主要侧重于将视图与BI分离。请专注于此。

有关保存数据的不同对象的详细信息,请参阅this答案。

答案 1 :(得分:2)

您可能想首先区分MVC模式和3层体系结构。总结一下:

3层架构:

  • 数据:持久数据;
  • 服务:应用程序的逻辑部分;
  • 演示:hmi,网络服务...

现在,对于上述3层架构,MVC模式发生在它的表示层中(对于Web应用程序):

  • 数据:...;
  • 服务:...;
  • 演示:
    • 控制器:拦截HTTP请求并返回HTTP响应;
    • 模型:存储要显示/处理的数据;
    • 视图:组织输出/显示。

典型HTTP请求的生命周期:

  1. 用户发送HTTP请求;
  2. 控制器拦截它;
  3. 控制器调用适当的服务;
  4. 该服务调用适当的dao,该dao返回一些持久数据(例如);
  5. 服务处理数据,然后将数据返回给控制器;
  6. 控制器将数据存储在适当的模型中并调用适当的视图;
  7. 该视图使用模型的数据实例化,并作为HTTP响应返回。