architecture - 为什么 Repository Pattern 的例子从不处理数据库连接异常？

Question

我已经阅读了很多教程，也看到了很多关于 Repository 实现的代码示例。图案。在几乎所有情况下，都没有解决因在数据库不可用时尝试访问数据库而导致的异常。考虑到如果数据库位于网络上的某个位置，这是一个非常现实的场景，这似乎很奇怪。

那么处理这些异常的最佳实践是什么？

将这一百个调用中的每一个都包装在一个 try/catch 中，其中每个调用都可能有
相同的n个catch块？这是很多重复、凌乱、容易出错等问题。

让异常冒泡到应用程序级别并捕获它们
未处理的异常？如果在 UI 线程上抛出异常，这是有道理的，但否则，处理未处理的 AppDomain 异常会导致应用程序关闭。

使用框架，例如 Enterprise Library 的 Exception
处理应用程序块？

Answer 1

老实说，我认为它没有得到解决，因为关于如何处理异常的持续(和情绪化)辩论。关于异常是应该在本地处理(更有可能理解它们并做一些智能的事情，比如重试)还是在 UI 层处理(其中 99.9% 的异常最终会冒泡)，一直在反复讨论。

就我个人而言，我发现在 Repository 层中执行 try/catch、捕获特定于数据库的异常并抛出我自己创建的新异常是最优雅的。这给了我一个放置重试逻辑的地方。然后，我还可以决定 DAOException 是检查异常还是运行时异常。

这允许用户界面处理已知异常，并帮助我将更高级别的层与任何特定于提供程序的错误隔离开来。例如，如果我将数据存储迁移到像 Mongo 或 Cassandra 这样的 No-SQL 数据库，我仍然可以抛出相同的异常，并保持它们的语义含义，而无需更改所有调用代码。