我正在创建一个3层应用程序。基本上，它会正确抽象3层系统中的数据库层？
客户端 - >（通过可选的服务器 是瘦客户机） - >业务逻辑 - > 数据库层
，基本上使得它，以便从未有任何跳跃周围。因此，我希望所有的SQL查询都在数据库层。
那么，现在我有点困惑。我做了几个静态类来启动数据库层，但我应该如何处理数据库连接？我是否应该在任何时候创建一个新的数据库连接，然后进入数据库层，否则会浪费？每当你有一个ConnectionPool时，Connection.Open（）是否需要时间？
对我来说，业务层必须将IdbConnection对象传递到数据库层才是错误的。看起来数据库层应该处理所有特定于DB的代码。你怎么看？如何在保持实用性的同时以正确的方式做到这一点？
由于ConnectionPool，每次访问数据库时都会打开一个新连接通常不成问题。
如果您可以重复使用，不留连接打开很长一段时间打开的连接，并且没有冒着留下孤儿打开的连接，那么它不会伤害重用打开的连接。 （我实际上将一个数据工具注入到所有访问数据库的类中，这主要是为了单元测试的目的，但它也允许我可以选择保持一个连接打开，以便多次调用数据库。）
但再次，你不应该过多地关注打开/关闭很多连接。这是更重要你的DAL：
只有在需要时才打开连接。 不要维护与数据库的连接，这会浪费得多。 当然你的数据库层会打开连接，林不知道为什么你认为BLL将传递连接到数据库。 BLL不知道数据库（至少它不应该），它应该处理业务规则等。实际连接在db层打开。
这里是展示BLL应该是什么样子的链接：
连接字符串本身应该仅仅是你的数据库层类中的一个私有变量，你应该能够拉连接字符串来自说一个web.config文件的信息。
是的，但它取决于应用程序。如果您每天运行一百万条查询，您将需要持续连接以避免不断设置新连接的开销。 – 2010-03-30 17:04:29
@Justin - 我更多的是试图解释BLL的功能。你所说的是另一个话题。更多的信息将需要从OP。 – JonH 2010-03-30 17:06:00
您可以创建一个类（或类的名称空间，具体取决于大小）来托管数据库层。在您的数据库类中，您应该只使用数据库层中的连接池。该池将在任何给定时间保持n个连接对数据库开放的连接数，因此您可以使用其中一个池连接运行查询，而不会产生大量开销。
有了这个，你的数据库层应该提供一个业务层可以调用的公共方法的“API”。这些方法都不应公开数据库连接对象 - 这些细节在数据层内部。
然后从您的业务层，每次需要运行查询时调用数据库层的“API”。
这有帮助吗？
可以在每次进入数据库层时创建并打开一个新连接，并在完成后立即关闭连接。 .Net/Sql Server可以很好地处理连接池，使其成为可行的方法。
您也是对的，您不会从业务层传入连接字符串。这应该是数据层的私有（但可配置）成员。
传统上，单独的“数据访问层”提供用于检索和提交数据的数据库上下文。有几个众所周知的模式，比如Repository。 ADO.NET实现了其他几个，比如Provider。
实体框架和LINQ to SQL也是进一步封装和简化数据层隔离的好选择。
有没有什么特别的原因让你不使用ORM？我发现它可以节省20-50％的开发时间，而无需手工编写SQL查询，更不用说连接管理，缓存和所有其他方面的好处了。 – 2010-03-30 17:03:46
因为这是一个微不足道的过程，让我们的旧项目与SQL的垃圾负载并把它带到新的项目。 – Earlz 2010-03-30 17:05:30
以下任何答案都可以帮助你解决问题吗？ – JonH 2010-03-30 18:07:37