问题标签 [data-access-layer]

我来自一个喜欢构建自己的世界而不是依赖他人构建的库和框架的世界。逃离这个世界后，我发现在 Visual Studio 中使用 Typed DataSets 等工具的乐趣和轻松。那么除了失去灵活性之外，你还失去了什么？是否有性能因素（忽略 procs 与动态 sql 的争论）？限制？

我很久以前开始了一个项目，并在我的解决方案中创建了一个数据访问层项目，但从未在其中开发过任何东西。数据访问层的目的是什么？有什么好的资源可以让我了解更多关于数据访问层的信息吗？

我有一个使用 NHibernate 作为其 ORM 的应用程序，有时由于它如何访问数据而遇到性能问题。可以做哪些事情来提高 NHibernate 的性能？（请限制每个答案推荐一个）

我正在使用相当标准的 Web/服务/数据访问分层设计构建一个用于娱乐/学习的小型网站。

为了使我不必经常创建服务层/数据访问层类的实例，我将它们中的方法全部设为静态。我不应该遇到并发问题，因为它们使用局部变量等并且不共享任何资源（目前事情很简单）。

据我所知，唯一的权衡是我并没有真正遵循真正的 OO 方法，但它再次使代码更加简洁。

有什么理由这不是一种可行的方法吗？以后可能会出现什么样的问题？有一个“工厂”类可以根据需要返回服务和数据层类的实例会更好吗？

我正在开发一个应用程序，该应用程序应该在收到 PayPal 即时付款通知时创建产品（如运输保险单）。不幸的是，PayPal 有时会发送重复的通知。此外，还有另一个第三方在从 PayPal 获取更新时同时执行 Web 服务更新。

这是所涉及的数据库表的基本图。

这是我想要做的基本图表：

如果有两个（或更多）线程（或进程或应用程序）同时执行此操作，我希望第一个线程在没有 policyID 时锁定“包”行，直到创建策略并分配 policyID到包装表。然后在将 policyID 分配给包表后，将释放锁。我希望调用相同代码的另一个线程在读取包行时会暂停，以确保它首先没有 policyID。当第一个事务的锁被释放时，我希望第二个事务将看到 policyID 在那里，因此返回而不在策略表中插入任何行。

注意：由于 CRUD 数据库设计，每个存储过程都涉及读取（选择）、创建（插入）或更新。

这是RepeatableRead事务隔离的正确使用吗？

谢谢。

我记得读过其中一个将低级别调用抽象为与数据无关的框架（例如 ExecuteCommand 方法等），而另一个通常包含特定于业务的方法（例如 UpdateCustomer）。

这个对吗？哪个是哪个？

我最初是按照这篇 codeproject 文章中概述的 s# 架构示例来设计我的系统的（不幸的是，我没有使用 NHibernate）。基本思想是，对于需要与持久层通信的每个域对象，您将在不同的库中拥有相应的数据访问对象。每个数据访问对象都实现一个接口，当域对象需要访问数据访问方法时，它总是针对接口进行编码，而不是针对 DAO 本身进行编码。

当时，我仍然认为这种设计非常灵活。然而，随着我的领域模型中对象数量的增加，我发现自己在质疑这里是否存在组织问题。例如，几乎域中的每个对象都以相应的数据访问对象和数据访问对象接口结束。不仅如此，而且每一个都位于不同的位置，如果我想做一些简单的事情，比如在一些命名空间周围移动，这将更难以维护。

有趣的是，这些 DAO（及其相应的接口）中的许多都是非常简单的生物——最常见的只有一个 GetById() 方法。我最终得到了一大堆对象，例如

他们的实现者通常也很琐碎。这让我想知道朝不同的方向前进是否会更简单，也许通过为简单的数据访问任务设置一个对象来改变我的策略，并为那些需要更多东西的人保留专用数据访问对象的创建复杂。

有没有人对这样的架构有任何经验？总的来说，我对设置非常满意，因为现在我唯一关心的是管理所有这些小文件。但是，我仍然想知道还有哪些其他构建数据访问层的方法。

只是想收集关于 LINQ 应该（以及为什么）属于哪个层的不同想法和观点？

在设计业务对象时，我尝试了几种不同的方法来编写数据访问层。有些人比其他人做得更好，但我一直觉得必须有一个“更好”的方法。

我真的很想看看人们在不同情况下处理 DAL 的不同方式，以及他们对该技术如何运作或运作不佳的看法。

我正在做一个小项目，我第一次想使用 XML 作为唯一的数据源……基于文件的存储适合项目的需要。

在编写 DAL 时，我应该将所有 get 方法都设为静态吗？避免和“文件打开时读取”错误？我应该在文件上使用 CacheDependency 吗？

谢谢