问题标签 [data-access-layer]

使用 DTO 在对象关系层和数据访问层之间传输数据是否有意义？这种模式什么时候有用，什么时候是反模式

几年后，我重新开始了 .NET 开发，现在看来，尤其是使用 LINQ，访问数据的方式已经改变并且变得更加容易。例如，在 ASP.NET MVC 网站中，我可以：

• 添加项目
• 添加 LINQ-to-SQL 类
• 将数据库表拖到 LINQ-to-SQL 对象关系设计器上，单击保存
• 通过 LINQ 单线访问和操作我的数据（我在这里学到：http ://www.asp.net/learn/mvc/tutorial-11-cs.aspx ）

这看起来很棒，但它有多真实？

• 上面的 LINQ-to-SQL 场景是您在实际项目中使用的东西，还是只是一种快速的脚手架技术，即当您开始添加、删除数据库中的字段和表时会发生什么，LINQ-to-SQL 类如何保持同步？

我如何理解这个领域的所有新技术，例如

• 亚音速适合哪里？
• Astoria（ADO.NET 数据服务）在哪里适合？
• NHibernate 适合哪里？
• 如何将其他数据库与 LINQ-to-SQL 一起使用（我尝试在对象关系设计器上拖动 SQLite 表并得到“不支持的错误”）或者 LINQ-to-SQL 仅适用于 SQL Server？
• LINQ-to-XML 是否像 LINQ-to-SQL 一样工作，例如我可以将 XML 文件拖到设计器上，然后使用 LINQ 访问它们，还是我需要为此编写自己的代码？

• LINQ-to-Entities 是否像 LINQ-to-SQL 一样工作，即自动生成的类，但只有更多选项？

• 既然我们有了 LINQ，ADO.NET 及其 DataTables 和 DataSets 是不是一项旧技术？LINQ-to-ADO.NET 有意义吗？

• Azure 适合您甚至不再拥有 RDBMS 的地方

• 当您的 UI 只是以 REST 方式与 WCF 对话或与 Web 服务对话时，ESB 适合什么？

既然我们有这么多的选择，如果你可以为一个项目选择这些技术中的任何一种，你会选择哪一种，为什么？

我正在寻找令人满意的选项来对我的 .NET DAL 类进行单元测试；因为它们是 DAL 类，所以它们直接使用 ADO.NET 访问数据库。目前我使用 MSSQL 数据库的实例进行测试，但想知道有哪些更快的选项——因为单元测试需要尽快运行，内存中的解决方案将是理想的。

我还应该提到我已经将自己绑定到 TSQL，因为我只会使用 Microsoft 平台。

我正在编写一个数据访问层。我对管理系统中的连接感到困惑。我知道.net 使用连接池。但我不想在所有 dml 操作或所有 sql 查询中打开和关闭数据库连接。我该如何处理？应该在何时何地（可能在使用数据访问层或数据访问层的全局 asax 中）管理连接？

我正在构建一个 MVC Web 应用程序（使用 Spring MVC 框架），我对设计特定区域的最佳方式感到有些困惑。

应用程序必须与一系列 Web 服务进行交互，这些 Web 服务的设计并没有那么大，并且它们本身并没有提供太多抽象 - 基本上每个创建/更新/检索/删除操作都有一个 Web 服务方法每个“数据类型”，除此之外没有太多的 API。Web 服务客户端需要知道调用哪些方法以及调用顺序，以便能够创建它需要的数据——换句话说，没有基于“事务”的方法。

例如，简单地创建一个新用户帐户需要调用总共七种不同的 Web 服务方法来设置必要表中的所有记录（一条user记录、为该用户添加正确privileges的、设置用户的billing详细信息等） .

我正在努力寻找将其抽象化并将其封装在我们的应用程序中的最佳方法。大多数应用程序都遵循标准流程：

在我的应用程序中，我使用自己的一组“域对象”来表示和抽象 Web 服务 WSDL 中定义的数据类型，这样我的域逻辑不依赖于 Web 服务类型，因此我们可以抽象和隐藏我们喜欢的任何细节。

我正在寻找一些意见是设计我上面作为示例提到的“用户创建过程”的最佳方式。正如我所提到的，创建“普通用户”的过程涉及调用七种不同的 Web 服务，但这只是用户的一种“类型”——我们必须能够创建几种不同类型的用户，每一种都需要不同的要调用的 Web 服务。

目前我只设计了这个“普通用户”的创建，作为一个概念证明——我有一个域对象User，一个UserDao接口，它有和的方法getUser(name)，createUser(User)以及一个WebServiceUserDao实现UserDao方法并知道如何调用上述内容的接口——提到了七种网络服务方法。该createUser()方法由 a 调用UserCreationService，这是我的业务/服务级别类，而该类又由SignupController.

但是为了扩展这个逻辑以便能够创建不同的用户类型（它们User.getType()由：

1. 为每个“用户类型”创建一个UserDao实现，因此创建每个“用户类型”的逻辑可以封装在它自己的类中，让UserCreationService决定UserDao使用哪个？这将对应于 1 个服务类：许多 DAO。
2. 我是否应该将它们UserDao分成更小的部分，一个对应于需要在 Web 服务/数据库中创建的每个“记录”，即使我的整个应用程序不需要了解这些单独类型中的每一个？然后UserCreationService对各种不同的“用户类型”有不同的实现？换句话说，即使我不需要相应的或域对象，该策略也会有 a PrivilegesDao、 a等。这将是许多服务类：许多 DAO。BillingPlanDaoPrivilegeBillingPlan
3. 包含所有需要为每个“用户类型”调用 Web 服务的逻辑WebServiceUserDao？这将具有一个非常复杂的类的缺点（并且 PMD 已经在抱怨圈复杂性），但是所有这些逻辑都将封装在一个类中，并且从整体 API 的角度来看可能会导致更少的复杂性。

我对这个应用程序的一个目标是确保如果我们必须更改数据持久性的细节，我们需要做的就是更改 DAO 实现——如果我们必须开始与不同的计费系统交互，除了在 DAO 级别之外，我不希望应用程序的任何部分发生更改。

有什么意见吗？当“业务逻辑”和“数据访问逻辑”似乎重叠时，您在决定在哪里分解它们时使用什么样的策略？

我有一个基本的域对象，比如由数据库中的单个表表示的 Person 或 Campaign 或 Event。但是，我也有这些对象的更复杂版本，例如 PersonCampaign 或 PersonEvent 甚至是理论上可以扩展基础对象之一的 CampaignEvent。

然而，由于多种原因，这变得复杂，因为 PHP 不支持多重继承（例如 PersonEvent 扩展 Person 或 Event）。并且还因为一些域对象实际上是具有不同属性和功能的工厂对象（例如，事件实际上是按电子邮件、电话、传真等事件类型的子类）。

我能看到的最简单的解决方案是根据从数据访问层返回的数据来更改对象的实际性质。

有没有人有更好的方法来处理这个问题？或者创建可以根据数据访问层当前可用的内容更改属性和行为的统一域对象是否正确？

DAO 模式和 Data Mapper 模式有区别吗？DAO 只是做 Data Mapper 的一种吗？

我有一个调用我的实体框架模型的 DAL。这些调用返回诸如 IOrderedQueryable 和 IQueryable 对象之类的东西。我应该将它们转换为我的 DAL 中更通用的东西，例如 List 吗？但我假设如果我不需要枚举整个集合，这可能是浪费......那么最好的方法是什么？只需让 DAL 返回 IQueryable<> 并在需要时转换它？还是有其他更灵活的东西？提前致谢。

我将我的 DAL 从使用 LINQ 切换到实体框架。因为我的应用程序根据当前用户连接到不同的数据库，所以我需要在运行时动态创建 DataContext 并传入适当的连接字符串。但是，当我尝试使用旧连接字符串以编程方式创建实体框架连接时，连接失败。它抱怨它无法识别连接字符串中的键，确切地说是“服务器”。

我发现我需要这样做才能使实体框架连接正常工作：

为什么是这样？
元数据属性有什么用？
对于多个不同的连接，它总是相同的，这会是一个问题吗？
应该是什么？
有没有办法解决？

提前致谢！

更新 1：感谢 Randolpho 的更新，但是......
我遇到这个问题的全部原因是我无法将连接字符串存储在配置文件中。连接字符串在运行时由用户连接动态确定。

这是我的确切场景：
如果用户 A 正在连接，应用程序从数据库 A 中提取数据。如果用户 B 正在连接，应用程序从数据库 B 中提取数据。
连接字符串存储在主数据库中，并且数量可能是无限的. 每次添加用户时，我都不想进入 web.config，更不用说它最终会变得巨大的事实！

是否有任何 .Net O/R（对象/关系）映射器提供开箱即用的异步方法？

如果可能的话，我不想为异步方法编写样板

我使用 CCR 框架使用异步方法推出了自己的 DAL。CCR 基本上要求我不要阻止它的任何线程等待 IO 响应。

到目前为止，我的解决方案的好处在于它已降至最低限度。但是随着这个项目在规模和功能方面的增长，我面临着维护原始 SQL 查询和样板代码的艰巨任务。

但另一方面，如果 O/R 映射器异步方法真的只是一个杂乱无章的 hack，它会增加复杂性，我也不会好过。

请不要专注于异步编程的替代方案。