我正在使用类似于 MVC 的模式构建应用程序。情况是下一个：在模型的上下文中对关联的存储库进行更改。如果更改引发异常，向用户显示有关错误信息的正确方法是什么？在我的程序的先前版本中，当我有 spaguetti 代码组织（模型、视图、控制器重叠）时，启动一个消息框告诉用户错误并不奇怪，因为我几乎从视图中做所有事情。现在在这个新版本中，我想正确地做事情，所以我想在模型层中做任何有视觉表示的事情都是不好的。前段时间我问什么是捕获异常的正确方法。我所指的具体点是将异常从内部代码扩展到上层，而不是在最上层捕获它们。几乎所有的响应都不是一个好的方法规模异常（捕获并再次抛出以被负责任的实体捕获），并且最好在最上层捕获。所以我脑子里有这个冲突。我在想保持关注点分离以扩大规模是不可避免的，但这与之前的建议相冲突。我该如何进行？但这与之前的建议相冲突。我该如何进行？但这与之前的建议相冲突。我该如何进行？
问问题
481 次
1 回答
2
一种常见的模式是在现有模型中放置错误的通用位置。
一种简单的方法是让您的模型类全部继承自具有 type 属性IEnumerable<ErrorBase>或您选择的其他类型的基本模型类。
然后，在您的演示者中，您可以根据需要检查错误收集和显示。
至于有异常冒泡，我使用的方法（几乎不管我正在构建什么类型的应用程序）是只处理较低级别的异常，如果你要进行一些特殊的日志记录（比如记录重要的局部变量），或者如果您可以在该例外情况下做一些智能的事情。否则，让它冒泡。
在您的演示者（或 Web 服务类或其他）之前的那一层，您可以捕获您的异常，进行常规日志记录，并将它们包装（或替换为）“净化”异常。对于 UI，您只需确保不泄露敏感数据，并尽可能显示友好消息。对于 Web 服务，您将它们变成了某种故障。等等。
最上层对冒泡异常不“负责”，他们只是负责确保这些异常不会以您不想要的形式显示给最终用户（或 Web 服务客户端或其他）他们……换句话说，你正在适当地“展示”他们。
请记住，关注点分离是您应该作为经验法则遵循的范式，而不是拥有一切的法令。就像泄漏的抽象一样，也有泄漏的范式。做有意义的事，不要太担心。:)
于 2011-03-08T02:22:37.667 回答