问题标签 [data-access-layer]

只是想知道是否有人对如何测试数据访问方法有任何想法。我发现测试检索数据访问方法要容易得多，因为我可以模拟出ExecuteReader并返回一个填充的dataTable.CreateDataReader(). 通过这样做，我可以测试如果返回结果集，我的对象是否正确填充。

但是我如何将其转换为我的持久方法（即添加、更新、删除等）。我要测试的是它是否正确填充命令参数等。

有任何想法吗？干杯

我一直在研究为我正在设计的新的基于 Web 的项目使用什么数据层，并且我非常热衷于将 LINQ 与 SQL 结合起来。它明显的简单性、灵活性和设计器支持确实很有吸引力，并且与 SQL Server 的隐式连接很好。

然而，最近宣布 LINQ to SQL 将退居到实体框架之后，因为它已被传递给 ADO.NET 团队 ( http://blogs.msdn.com/adonet/archive/2008/10 /29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx）。当然，它会在未来得到支持，但不太可能看到更多的开发工作。

考虑到这一点，您会推荐我在我的项目中使用这项技术，还是值得选择替代 ORM（nHibernate？）或手动编写通用 DAL？

该项目本身是基于 ASP.NET 和 SQL Server 2005/2008 的，并且可能会使用 MVC，即使它仍处于测试阶段。这是一个个人项目，数据库不会过于复杂，主要用作看.NET未来技术的原型。不过，我会将未来的项目建立在我从这个项目中学到的东西上，所以我做出的选择会影响到更大的解决方案。

是的，我意识到微软明天可能会推出全新的数据访问技术！;)

我目前被困在这个解决方案的设计中。

数据层设计包括以下内容：

• 配方（父高级对象）
  • 语言详细信息（名称，按语言描述）（很多）
    • 标头（很多）
    • 步骤（很多）
      • 成分（很多）
      • 数量（许多）
      • 手续（多）
    • 笔记（很多）

我面临的挑战是如何创建一个数据访问设计，当从 WCF SaveRecipe(recipe) 方法填充对象时，该设计将添加/删除数据库中的子对象？

这都是因为管理层要求我们在应用中增加一个通信层，现在我们的UI耦合到我们的业务层，而BL直接耦合到DAL，我们基本上需要在BL和DAL之间注入WCF .

我在这个线程中读到，使用 L2S 不是 WCF 的好主意，但由于设计不是新的，我们必须使用这种类型的方法，然后一旦我们可以重构大量用户界面工作。

我正在为使用 Pervasive SQL 数据库存储信息的服务业务管理应用程序开发 Web 界面（顺便说一句，这不是我的选择）。目前，我正在使用带有一组自定义查询生成类的官方 Pervasive SqlClient 实现，因此我可以编写如下代码：

到目前为止它工作正常，但我在这里和那里遇到了一些小问题。与其继续朝着这个方向前进，我更愿意使用经过验证的 DAL。但是，我在找到可以与 Pervasive 数据库交互的 DAL 系统时运气不佳。

Opf3 有一个 Pervasive 存储提供程序，但我以前从未听说过该框架，并且该网站仅显示 Pervasive v8 徽标，而我需要可以与 v9.5 以及未来 v10 一起使用的东西。

我尝试编写 NHibernate 提供程序，但结果比我当前的查询生成系统更令人头疼。

你有什么建议？我的时间线很匆忙，所以我想要一些尽可能容易整合的东西。

最近我发现自己正在编写数据访问层选择方法，其中代码都采用这种一般形式：

或者像这样：

这些方法将由业务层代码调用，然后将基本 DataTable 或 DataRecord 转换为表示层可以使用的强类型业务对象。

由于我反复使用类似的代码，我想确保这个代码是最好的。那么如何改进呢？而且，是否值得尝试将通用代码从这里移到它自己的方法中。如果是这样，该方法会是什么样子（特别是关于传入 SqlParameter 集合）？

DAL (customerDAL) 中的类不应该是单例的吗？由于我的控制器 (customerController) 公开了“Shared Subs”，因此在每次调用时，如果已经存在，则无需创建新的 DAL 对象。正确的？

谢谢

我想知道填充业务对象层次结构（父/子/孙子）结构的最佳实践来自单个数据库调用。

我可以想到几种方法来完成它，例如：

左连接我的 sql 语句中的所有关系，然后使用循环和逻辑来填充业务对象

或者

使用几个 select 语句和 1 个 datareader 并使用其 NextResult() 方法遍历每个结果集并填充相应的 BO

只是想知道最好的做法是什么

我正在为我的 DAL 使用 DAAB 和 c#

谢谢！

假设，我们创建了一个存储过程，它应该检索客户详细信息，并将在某种仪表板视图中使用。由于还有一些与仪表板相关的其他存储过程，人们可能会考虑通过相应地命名来对 SP 进行可视化分组：

• DASH_GetCustomerDetails
• 短跑_...

现在，如果您使用 .NET 2.0 创建标准 DAL，您肯定会添加强类型数据集并添加一些表适配器。默认情况下，上述 SP 的 TA 将命名为 DASH_GetCustomerDetailsTableAdapter，数据表为 DASH_GetCustomerDetailsDataTable，依此类推。

通常，您将拥有某种高于它们的业务逻辑。它可能被称为类似于 Customer 的东西，它具有一个实例化表适配器的受保护属性和一个 GetDetails 方法，可能最终检索详细信息。或者，您甚至可以将该方法本身设为属性，将其称为 Details，以便表示层可以只说类似 cust.Details 之类的内容。

但是，...我对所有这些命名的东西并不满意。是否有必要能够区分在后台工作的存储过程，以便命名应该反映......是否有任何最佳实践？

Microsoft 为 ASP.NET (2.0) 应用程序提供了此DAL/BLL 设计建议。我知道一些替代方案，并且我已经在 SO 上阅读了相关问题。但是我想知道这个提议的解决方案现在是否值得实施，你知道有什么具体的缺点吗？

我想开发 DAL/BLL 组件供公司内部使用，从各种应用程序和脚本访问客户和员工数据等。然而，在我开始构建这些东西之前，我想确保这个解决方案是“好的”。例如，BLL传递数据表而不是封装任何东西，您没有包含逻辑的隔离业务对象。它基本上只是一个愚蠢的层，可以稍微简化 CRUD 操作并允许控件的数据绑定。

在该领域有经验的人可以指出这种方法的优缺点吗？

需要记录一些“高风险”数据操作。在这种情况下，“高风险”操作被定义为写入我们的 ERP 系统。碰巧我们正在将这些事件记录到我们的 SQL Server 数据库中。

伪代码：

消除这种紧密耦合的最佳做法是什么？