【发布时间】：2010-09-08 18:21:52
【问题描述】：
我很久以前开始了一个项目，并在我的解决方案中创建了一个数据访问层项目，但从未在其中开发过任何东西。数据访问层的目的是什么？有什么好的资源可以让我了解更多关于数据访问层的信息吗？
【问题讨论】：
标签： terminology data-access-layer
【发布时间】：2010-09-08 18:21:52
【问题描述】：
两个字：Loose Coupling
将用于从数据存储（数据库、平面文件、Web 服务等）中提取数据的代码与业务逻辑和表示代码分开。这样，如果您必须更改数据存储，您最终不会重写整个内容。
如今，各种 ORM 框架都在将 DAL 与其他层混合在一起。这通常会使开发更容易，但更改数据存储可能会很痛苦。公平地说，像这样更改数据存储非常少见。
【讨论】：
-
> 这样，如果您必须更改数据存储，您最终不会重写整个内容。你们真的要改变数据存储吗？除非你从一开始就计划好，否则我对此表示怀疑。
-
嗯，在某些项目中我一直都在做。在我的开发环境中，我使用的是 SQLite，而在生产环境中使用的是 MySQL。我使用的框架使这很容易（Pylons）。
-
我记得很多例子都是“您可能需要使用 Oracle/MySql/SQL Server 而不是 SQLServer/Oracle/MySQL 作为数据存储”，但根据我的经验，这 从来没有因为工具和许可是大多数商业项目的核心。
-
如果只是对数据库模式进行重大更改作为这种松散耦合的原因呢？例如假设您在数据库的某些部分从规范化表更改为 EAV 表。
数据访问层有两个主要用途
抽象出实际的数据库引擎 或其他数据存储，这样您的 应用程序可以从使用切换 说 Oracle 使用 MS SQL 服务器
抽象逻辑数据模型，例如 你的业务层是 与这些知识脱钩并且是 不可知论者。给你 修改逻辑数据的能力 在不影响业务的情况下建模 层
这里的大多数答案都提供了第一个原因。在我看来，第二个更重要。本质上，您的业务层不应该知道正在使用的逻辑数据模型。今天，ORM 和 Linq #2 似乎已被淘汰，人们往往会忘记（或无法看到确实存在且应该存在的细线）关于 #2。
基本上，为了更好地理解数据层的目的和功能，您需要从业务层的角度来看待事物，请记住，业务层应该与数据存储的逻辑数据模型无关.
因此，例如，每次业务层需要数据时，是否应该以一种非常简单的与逻辑数据模型无关的方式来请求它需要的数据。所以它会调用数据访问层，例如：
GetOrdersForCustomer(42)
它准确地返回它需要的数据，而不知道哪些表存储了这些信息或存在关系等。
我在我的博客上写了一篇文章，介绍了更多细节。
【讨论】：
-
更新链接。不再访问
数据访问层遵循“关注点分离”的理念，即业务逻辑与数据层（数据库）交互所需的所有逻辑都被隔离到一组类（层）中。这使您可以更轻松地更改后端物理数据存储技术（例如，从 XML 文件移动到数据库，或从 SQL Server 移动到 Oracle 或 MySQL），而不会对您的业务逻辑。
有很多工具可以帮助您构建数据层。如果您搜索短语“对象关系映射器”或“ORM”，您应该会找到一些更详细的信息。
【讨论】：
-
> 这允许您更轻松地更改后端物理数据存储技术（例如从 XML 文件移动到数据库，或从 SQL Server 移动到 Oracle 或 MySQL）事后诸葛亮？我对此表示怀疑。
-
@Grauenwolf：虽然更改数据库并不那么频繁，但分离内容仍然是“做事的好方法”，在实践中更常见的是，您可能会改变访问当前的方式数据，或调整某些功能，并将其全部集中在一个地方。
当应用程序的许多不同部分需要以相同的方式访问数据时，数据访问层非常有意义。
当您需要以多种不同方式访问相同数据时，这也很有意义。例如，文字处理器如何读取许多不同的文件类型并将它们静默转换为应用程序的内部格式。
请记住，DAL 也可能适得其反。如果您正在构建一个数据访问性能至关重要的系统，那么将其与业务逻辑分开可能会使一些重要的优化变得不可能。
【讨论】：
-
我所做的是在我的 BAL 中实现数据访问。
-
LMAO，我的意思是 BLL（业务逻辑层）。
DAL 应该将您的数据库从项目的其余部分中抽象出来——基本上，除了 DAL 之外的任何代码中都不应该有任何 SQL，并且只有 DAL 应该知道数据库的结构。
目的主要是为了使您的应用程序的其余部分免受数据库更改的影响，并使其更容易扩展和支持您的应用程序，因为您将始终知道去哪里修改数据库交互代码。
【讨论】：
-
如果我将数据访问权限放在我的 BAL 中会怎样？
目的是抽象出应用程序其他部分不需要关心的数据库访问细节。
【讨论】：
数据访问层用于从其表示中抽象出数据的存储和检索。您可以在 1994 年的 Design Patterns 中阅读有关这种抽象的更多信息
【讨论】：
目的是从数据使用和操作中抽象出数据存储检索机制。
好处：
- 底层存储可能会发生变化（例如从 Oracle 切换到 MSSQL），您需要一种方法来本地化这些变化
- 架构更改 - 见上文
- 您想要一种在与数据库断开连接的情况下运行的方法（演示模式）：将文件序列化/反序列化添加到 DAL
【讨论】：
我建议你在这里阅读：http://msdn.microsoft.com/en-us/practices/default.aspx 使用 DAL 将帮助您将数据访问与演示和业务逻辑隔离开来。我经常使用它，以便我可以轻松地换出（通过反射和动态加载程序集）数据提供者。
阅读，那里有很多很好的信息。
另外，如果您打算使用 .NET，请查看Data Access Block。这可能是一个很大的帮助。
【讨论】：
我想补充的是，我想补充的是，拥有 DAL 可以提高系统的安全性。例如，数据库和 DAL 可以在公众无法访问的服务器上运行，而业务逻辑可以在面向公众的服务器上运行，这样公共服务器就不能在数据库上运行原始 SQL。如果公共服务器受到损害，这可以帮助减轻很多损害。
【讨论】：