三层系统中数据库层的正确抽象？
我正在创建一个 3 层应用程序。基本上就这样了
客户端-> （通过可选服务器 成为瘦客户端）->业务逻辑-> 数据库层
基本上做到了永远不会有任何跳过。因此，我希望所有 SQL 查询等都位于数据库层中。
好吧，现在我有点困惑了。我创建了一些静态类来启动数据库层，但是我应该为数据库连接做什么？我是否应该在进入数据库层时创建一个新的数据库连接，否则会很浪费吗？当你有 ConnectionPool 时，Connection.Open() 是否需要时间？
对我来说，业务层必须将 IdbConnection 对象传递到数据库层感觉是错误的。数据库层似乎应该处理所有特定于数据库的代码。你怎么认为？我怎样才能在保持实用的同时以正确的方式去做呢？
I am creating a 3 tier application. Basically it goes
Client -> (through optional server to
be a thin-client) -> Business Logic ->
Database Layer
And basically making it so that there is never any skipping around. As such, I want for all of the SQL queries and such to be in the Database Layer.
Well, now I'm a bit confused. I made a few static classes to start off the database tier but what should I do for the database connections? Should I just create a new database connection anytime I enter the Database Layer or would that be wasteful? Does Connection.Open() take time whenever you have a ConnectionPool?
To me, it just feels wrong for the Business tier to have to pass in a IdbConnection object to the Database tier. It seems like the Database tier should handle all of that DB-specific code. What do you think? How can I do it the proper way while staying practical?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
由于有了ConnectionPool，每次访问数据库时打开一个新连接通常不是问题。
如果您可以重用打开的连接，而无需长时间保持连接打开，并且不会冒留下孤立的打开连接的风险，那么重用打开的连接并没有什么坏处。 （实际上，我将一个数据工具注入到访问数据库的所有类中。这主要用于单元测试目的，但它也允许我选择保持连接打开，以供对数据库的多次调用使用。）
但同样，您应该不要过分强调打开/关闭大量连接。 更重要的是，您的 DAL：
Because of the ConnectionPool, open a new connection each time you access the db is usually not a problem.
If you can reuse open connection without leaving connections open a long time, and without risking leaving orphaned opened connections, then it doesn't hurt to reuse open connections. (I actually inject a datatool into all my classes that access the db. This is mainly for unit testing purposes, but it also allows me to optionally keep a connection open to be used by multiple calls to the db.)
But again, you should not stress too much about opening/closing a lot of connections. It is more important that your DAL:
仅在需要时打开连接。
不要维护与数据库的连接，那更加浪费。
当然，您的数据库层将打开连接，我不确定为什么您认为 BLL 会将连接传递给数据库。 BLL 不了解数据库（至少不应该），它应该处理业务规则等。实际的连接是在db层打开的。
以下链接显示了 BLL 的外观：
验证 .net 中的数据
连接字符串本身应该只是数据库层类中的私有字符串变量，并且您应该能够从 web.config 文件中提取连接字符串信息。
Only open the connection when you need it.
Do not maintain a connection to the database, that is much more wasteful.
Of course your db layer will open the connection, Im not sure why you think the BLL is going to pass a connection to the db. The BLL does not know about the database (at least it shouldnt), it should handle business rules and such. The actual connection is open at the db layer.
Here is a link that shows how the BLL should look:
Validating data in .net
The connection string itself should simply be a private string variable within your db layer class and you should be able to pull connection string information from say a web.config file.
每次进入数据库层就创建并打开一个新的连接，用完后立即关闭连接是可以的。 .Net/Sql Server 处理连接池的能力足以使这项工作正常进行，并且这是公认的方法。
您没有从业务层传递连接字符串也是对的。那应该是数据层的私有（但可配置）成员。
It's okay to create and open a new connection every time you enter the database layer, and close the connection as soon as you're finished with it. .Net/Sql Server handles connection pooling well enough to make this work, and it's the accepted way to do it.
You are also right that you don't pass your connection string in from the business layer. That should be a private (but configurable) member of the data layer.
传统上，单独的“数据访问层”提供用于检索和提交数据的数据库上下文。有几种众所周知的模式可以实现这一点，例如存储库。 ADO.NET 实现了其他几个，例如 Provider。
实体框架和 LINQ to SQL 也是进一步封装和简化数据层隔离的不错选择。
Traditionally, a separate "Data Access Layer" provides the database context for retrieving and committing data. There are several well-known patterns for this, such as Repository. ADO.NET implements several others, such as Provider.
Entity Framework and LINQ to SQL are also good options to further encapsulate and simplify the isolation of the data tier.
您可以创建一个类（或类的命名空间，取决于大小）来托管数据库层。在数据库类中，您应该只在数据库层使用连接池。该池将在任何给定时间保持 n 个对数据库打开的连接，因此您可以仅使用池连接之一运行查询，而不会产生大量开销。
完成此操作后，您的数据库层应该提供业务层可以调用的公共方法的“API”。这些方法都不应该公开数据库连接对象 - 这些细节是数据层内部的。
然后，每次需要运行查询时，从业务层只需调用数据库层的“API”即可。
这有帮助吗？
You can create a class (or namespace of classes, depending on the size) to host the database layer. Within your database class, you should just use a connection pool in the database layer. The pool will keep n number of connections open to the database at any given time, so you can just run a query using one of the pooled connections without incurring significant overhead.
With this in place, your database layer should present an "API" of public methods that the business layer can call into. None of these methods should expose a database connection object - those details are internal to the data layer.
Then from your business layer, just call into the database layer's "API" each time you need to run a query.
Does that help?