ASP.Net 中的数据访问层：在哪里创建连接？
如果我想创建一个 3 层 ASP.Net 应用程序（表示层、业务层、数据访问层），那么创建 Connection 对象的最佳位置在哪里？
到目前为止，我在表示层中使用了一个辅助类，从每个页面的 web.config 中的 ConnectionString 创建一个 IDbCommand，并将其传递给 DAL 类/方法。
现在我不太确定，这部分是否也不应该以某种方式包含在 DAL 中，因为它显然是数据访问的一部分。 DAL 位于单独编译的项目中，因此我无权访问 web.config，也无法访问连接字符串（对吗？）。
这里的最佳实践是什么？
If I want to create a 3-Layer ASP.Net application (Presentation Layer, Business Layer, Data Access Layer), where is the best place to create the Connection objects?
So far I used a helper class in my Presentation Layer to create an IDbCommand from the ConnectionString in the web.config on each page and passed it on to the DAL classes/methods.
Now I am not so sure, if this part shouldn't also be included in the DAL somehow, because it obviously is part of the Data Access. The DAL is in a separately compilated project, so I dont have access to the web.config and cannot access the connection string (right?).
What is the best practice here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
简短的回答：
连接对象代表对数据库的依赖，应该在数据访问层中创建（并且仅）。
长答案：
当你说“3层”时，你真正的意思是“层”还是“层”？前者建议在每层之间有一个硬边界，例如服务层。后者只是单个应用程序上下文中的逻辑分离。另外，以什么方式定义DAL是“单独编译的项目”？它可以访问运行代码的任何应用程序上下文的配置文件。如果它是它自己的层，它将有某种服务或具有配置的东西。如果它只是一个层，它可以访问应用程序的主要配置。
理想情况下，任何与数据库相关和/或依赖于数据库的内容都应该仅存在于 DAL 中。应用程序域的其余部分不必担心数据库。
Short answer:
The Connection objects, which represent a dependency to the database, should be created in (and known only to) the Data Access Layer.
Long answer:
When you say "3-Tier" do you really mean "tier" or do you mean "layer"? The former suggests a hard boundary, such as a service layer, between each tier. The latter is simply a logical separation within a single application context. Also, define in what way the DAL is "a separately compiled project"? It can access the config file for whatever application context is running the code. If it is its own tier, it would have some kind of service or something which has a config. If it's just a layer, it can access the application's main config.
Ideally, anything that's tied to and/or dependent on the database should exist only in the DAL. The rest of the application domain shouldn't have to worry about the database.
我认为它应该位于服务层，即满足用例的层。了解工作单元的对象应该是创建连接、设置事务级别、满足用例以及清理任何必要内容的对象。
它不应该在表示层中，因为如果您更改表示技术，则必须重新创建连接。
I think it ought to be in a service layer, the one that fulfills the use cases. The object that knows about units of work ought to be the one to create the connection, set the transactional level, fulfill the use case, and clean up whatever is necessary.
It shouldn't be in the presentation layer, because if you change presentation technology you have to redo the connection creation.