使用数据访问层时，是否应该将 SqlException 包装在自定义异常中？
如果我是正确的，那么数据访问对象接口背后的想法就是实际的存储，无论是数据库、文件还是 XML，都对客户端代码隐藏。但是，如果您使用 SqlCommand 和 SqlConnections 并且出现问题并抛出 SqlException，那么客户端代码就会意识到实现以及我们正在使用 MS Sql 服务器作为数据库的事实。所以我们可以更改客户端代码来捕获DbException。但随后我们会让客户了解实施情况。所以这对我来说似乎是一个有漏洞的实现。
我认为正确的方法是包装到客户端代码可以响应的自定义 DAL 异常中。 时，这似乎需要做很多工作
- 当数据库不太可能改变
- 。存储类型（数据库、文件、xml）更不可能改变。
在这种情况下，客户端代码应该只处理 SqlException 本身。客户端代码耦合得更紧密，但老实说我没有看到它发生变化。或者仍然值得包装异常吗？
If I am correct then the idea behind having an interface for data access objects is that the actual store, whether it is database, file, or XML is hidden from the client code. But if you are using SqlCommand and SqlConnections and something goes wrong and it throws a SqlException, then the client code becomes aware of the implementation and the fact that we are using a MS Sql server as the database. So we can change the client code to catch DbException. But then we are making the client aware of the implementation. So this seems like a leaky implementation to me.
I think the correct approach would be to wrap into custom DAL exceptions which the client code could respond to. It just seems like a lot of work to do when
- The database is unlikely to change.
- The store type (database, file, xml) is even more unlikely to change.
In this scenario should the client code just handle the SqlException itself. The client code is more closely coupled but I honestly don't see it changing. Or is it still worth wrapping the exceptions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您正在谈论持久性无知（并希望保留它），那么正确的是，您不应该让 SQL 异常按原样冒泡。
您应该创建自己的特定异常类型，并在实现中将任何异常与自定义异常（PeristenceExcpetion？）包装为
InnerException。话虽如此，如果您知道您不会更改存储类型和数据库，那么就没有理由解耦异常。
If you are talking about persistence ignorance (and wish to retain it), then correct, you shouldn't let SQL Exceptions bubble up as they are.
You should create your own specific exception types and in your implementation wrap any exception with your custom exception (PeristenceExcpetion?) as an
InnerException.Having said that, if you know that you are not changing your store type and database, then there is little reason to decouple the exceptions.
您的应用程序真的是 DBProviderIndependent 吗？您是否始终在内部使用 DbConnection 或 DbCommand 使用 DbProviderFactory 来创建它们？您的项目中没有引用 System.Data.SqlClient 吗？
如果您回答“否”，那么我不会花精力翻译该异常。 YAGNI
如果我真的需要数据库独立性，我会使用一个特殊的工具就像 (Fluent)NHibernate 一样，它负责处理 ExceptionMappings。
Is your application realy DBProviderIndependent? Do you always work internally with DbConnection or DbCommand using a DbProviderFactory to create them? There is no reference to System.Data.SqlClient in you project?
If you answer with "No" then I would not take the effort to translate the exception. YAGNI
If I realy need Database-Independence i use a special tool for that like (Fluent)NHibernate that takes care of ExceptionMappings.