在 3 层系统中正确抽象数据库层？答案

【问题标题】：Proper abstraction of the database tier in a 3 tier system?在 3 层系统中正确抽象数据库层？
【发布时间】：2011-02-02 13:47:09
【问题描述】：

我正在创建一个 3 层应用程序。基本上是这样

Client -> (通过可选的服务器到做一个瘦客户端）-> 业务逻辑-> 数据库层

并且基本上做到了，这样就不会有任何跳过。因此，我希望所有 SQL 查询等都在数据库层中。

嗯，现在我有点困惑。我做了一些静态类来启动数据库层，但是我应该为数据库连接做些什么呢？我应该在进入数据库层的任何时候创建一个新的数据库连接还是会浪费？每当您拥有 ConnectionPool 时，Connection.Open() 是否需要时间？

对我来说，业务层必须将 IdbConnection 对象传递给数据库层感觉不对。似乎数据库层应该处理所有特定于数据库的代码。你怎么看？我怎样才能在保持实际的同时以正确的方式做到这一点？

【问题讨论】：

【解决方案1】：

因为有ConnectionPool，每次访问db时打开一个新的连接通常是没有问题的。

如果您可以重用打开的连接而无需长时间打开连接，也不会冒着留下孤立的打开连接的风险，那么重用打开的连接并没有什么坏处。（实际上，我将一个数据工具注入到所有访问数据库的类中。这主要用于单元测试目的，但它也允许我选择保持连接打开以供多次调用数据库使用。）

但同样，您不应过分强调打开/关闭大量连接。 更重要的是您的 DAL：

【讨论】：

【解决方案2】：

仅在需要时打开连接。不要维护与数据库的连接，那样会更加浪费。当然，您的数据库层会打开连接，我不确定您为什么认为 BLL 会将连接传递给数据库。 BLL 不了解数据库（至少不应该），它应该处理业务规则等。实际连接是在 db 层打开的。

这是一个显示 BLL 外观的链接：

连接字符串本身应该只是你的数据库层类中的一个私有字符串变量，你应该能够从 web.config 文件中提取连接字符串信息。

【讨论】：

【解决方案3】：

每次进入数据库层都可以创建并打开一个新连接，完成后立即关闭连接。 .Net/Sql Server 可以很好地处理连接池以完成这项工作，这是公认的方法。

您没有从业务层传递连接字符串也是对的。这应该是数据层的私有（但可配置）成员。

【讨论】：

【解决方案4】：

传统上，单独的“数据访问层”为检索和提交数据提供数据库上下文。有几种众所周知的模式，例如 Repository。 ADO.NET 实现了其他几个，例如 Provider。

Entity Framework 和 LINQ to SQL 也是进一步封装和简化数据层隔离的不错选择。

【讨论】：

【解决方案5】：

您可以创建一个类（或类的命名空间，取决于大小）来托管数据库层。在您的数据库类中，您应该只使用数据库层中的连接池。该池将在任何给定时间保持 n 个对数据库打开的连接，因此您可以使用其中一个池连接运行查询，而不会产生大量开销。

有了这个，你的数据库层应该提供一个业务层可以调用的公共方法的“API”。这些方法都不应该公开数据库连接对象——这些细节在数据层内部。

然后从您的业务层，每次您需要运行查询时，只需调用数据库层的“API”。

这有帮助吗？

【讨论】：