我正在创建一个3层应用程序。基本上就是
客户 - ＆gt; （通过可选服务器到 是一个瘦客户端） - ＆gt;业务逻辑 - ＆gt; 数据库层
并且基本上是为了让它永远不会跳过。因此，我希望所有的SQL查询都在数据库层中。
嗯，现在我有点困惑。我做了一些静态类来启动数据库层，但是我应该怎么做数据库连接？我是否应该在进入数据库层时创建新的数据库连接，还是浪费？每当有ConnectionPool时，Connection.Open（）是否需要时间？对我而言，业务层必须将IdbConnection对象传递给数据库层才感觉不对。似乎数据库层应该处理所有特定于DB的代码。你怎么看？如何在保持实用的同时以正确的方式做到这一点？
答案 0 :(得分：2)
仅在需要时打开连接。 不要保持与数据库的连接，这样会更加浪费。 当然你的数据库层将打开连接，我不知道为什么你认为BLL将传递连接到数据库。 BLL不知道数据库（至少它不应该），它应该处理业务规则等。实际连接在db层打开。
以下链接显示了BLL的外观：
连接字符串本身应该只是db层类中的私有字符串变量，您应该能够从web.config文件中提取连接字符串信息。
答案 1 :(得分：2)
您可以创建一个类（或类的命名空间，具体取决于大小）来托管数据库层。在数据库类中，您应该只在数据库层中使用连接池。在任何给定时间，池将保持n个连接对数据库开放，因此您可以使用其中一个池连接运行查询，而不会产生大量开销。
有了这个，您的数据库层应该呈现业务层可以调用的公共方法的“API”。这些方法都不应公开数据库连接对象 - 这些细节是数据层内部的。
然后，从您的业务层，每次需要运行查询时，只需调用数据库层的“API”。
这有帮助吗？
答案 2 :(得分：2)
每次进入数据库层时都可以创建并打开一个新连接，并在完成连接后立即关闭连接。 .Net / Sql Server可以很好地处理连接池，使其能够正常工作，并且这是可接受的方法。
您也没有从业务层传递连接字符串。这应该是数据层的私有（但可配置）成员。
答案 3 :(得分：2)
传统上，单独的“数据访问层”提供用于检索和提交数据的数据库上下文。有几种众所周知的模式，例如Repository。 ADO.NET实现了其他几个，例如Provider。
实体框架和LINQ to SQL也是进一步封装和简化数据层隔离的好选择。
答案 4 :(得分：2)
由于ConnectionPool，每次访问db时都打开一个新连接通常不是问题。
如果，您可以重复使用开放连接，而不会让连接长时间打开，并且没有冒着离开孤立的连接的风险，那么重用开放连接并不会有害。 （我实际上将数据库注入到我访问数据库的所有类中。这主要用于单元测试目的，但它也允许我选择保持连接打开以供多次调用数据库使用。）
但同样，你不应该过多地强调打开/关闭很多连接。你的DAL
是更重要