数据访问层的目的是什么?

时间:2008-09-12 20:59:43

标签: terminology data-access-layer

我很久以前就开始了一个项目,并在我的解决方案中创建了一个数据访问层项目,但从未开发过任何内容。数据访问层的目的是什么?有没有什么好的资料可以让我了解更多有关数据访问层的信息?

10 个答案:

答案 0 :(得分:15)

用两个词来说:Loose Coupling

保持用于从数据存储(数据库,平面文件,Web服务等)中提取数据的代码,与业务逻辑和表示代码分开。这样,如果你必须改变数据存储,你最终不会重写整个事物。

现在,各种ORM框架将DAL与其他层混合在一起。这通常使开发更容易,但更改数据存储可能会很痛苦。公平地说,更改这样的数据存储是非常罕见的。

答案 1 :(得分:9)

数据访问层有两个主要目的

  1. 抽象实际的数据库引擎 或其他数据存储,这样你的 应用程序可以从使用中切换 说Oracle要使用MS SQL服务器

  2. 摘要逻辑数据模型等     您的业​​务层是     与这种知识分离并且是     不可知论者。给你的     能够修改逻辑数据     模型不影响业务     层

  3. 这里的大部分答案都提供了第一个理由。在我看来,第二个更为重要。基本上,您的业务层不应该知道正在使用的逻辑数据模型。今天,ORM和Linq#2似乎走出了窗外,人们往往会忘记(或者无法看到有关#2的细线)。

    基本上,为了更好地理解数据层的目的和功能,您需要从业务层的角度看待事物,请记住,业务层应该与数据存储的逻辑数据模型无关。

    因此,每次业务层需要数据时,如果应该以非常简单的逻辑数据模型不可知的方式询问它所需的数据。因此,它会调用数据访问层,例如:

    GetOrdersForCustomer(42)
    

    它可以准确地获取所需的数据,而不会知道哪些表存储了此信息或存在关系等。

    我在博客上写了一篇文章,详细介绍了这篇文章。

    The Purpose and function of a Data Access Layer

答案 2 :(得分:5)

数据访问层遵循“关注点分离”的概念,即业务逻辑与数据层(数据库)交互所需的所有逻辑都被隔离到一组类(层)。这使您可以更轻松地更改后端物理数据存储技术(例如,从XML文件迁移到数据库,或从SQL Server迁移到Oracle或MySQL),而不会对您的影响产生巨大影响(如果做得对,则影响为零)商业逻辑。

有很多工具可以帮助您构建数据层。如果您搜索短语“object relational mapper”或“ORM”,您应该找到更详细的信息。

答案 3 :(得分:4)

当应用程序的许多不同部分需要以相同的方式访问数据时,数据访问层很有意义。

当您需要以多种不同方式访问相同数据时,这也是有意义的。例如,字处理器如何读取许多不同的文件类型,并将它们静默地转换为应用程序的内部格式。

请记住,DAL也可能非常适得其反。如果您正在构建一个数据访问性能至关重要的系统,那么将其与业务逻辑分离可能会使一些重要的优化变得不可能。

答案 4 :(得分:2)

DAL应该从项目的其余部分抽象出数据库 - 基本上,除了DAL之外的任何代码中都不应该有SQL,只有DAL应该知道数据库的结构。

目的主要是将应用程序的其余部分与数据库更改隔离开来,并使您更容易扩展和支持您的应用程序,因为您始终知道在哪里修改数据库交互代码。

答案 5 :(得分:1)

目的是抽象出应用程序的其他部分无需关注的数据库访问详细信息。

答案 6 :(得分:1)

数据访问层用于从其表示中抽象出数据的存储和检索。你可以在1994年的Design Patterns

中阅读更多关于这种抽象的内容

答案 7 :(得分:1)

目的是从数据使用和操作中抽象出数据存储检索机制。

优点:

  • 底层存储可以更改(例如从Oracle切换到MSSQL),您需要一种方法来本地化这些更改
  • 架构更改 - 见上文
  • 您想要一种与数据库断开连接的方法(演示模式):向DAL添加文件序列化/反序列化

答案 8 :(得分:0)

我建议你在这里阅读:http://msdn.microsoft.com/en-us/practices/default.aspx 使用DAL将帮助您将数据访问与演示文稿和业务逻辑隔离开来。我经常使用它,以便我可以轻松地换出(通过反射和动态加载程序集)数据提供程序。

阅读,那里有很多好消息。

另外,如果您打算使用.NET,请查看Data Access Block。这可能是一个很大的帮助。

答案 9 :(得分:0)

我认为我添加的一些尚未提出的东西是,使用DAL可以提高系统的安全性。例如,DB和DAL可以在公众无法访问的服务器上运行,而业务逻辑可以在面向公众的服务器上运行,使得公共服务器无法在DB上运行原始SQL。如果公共服务器受到损害,这可以帮助减轻大量损害。