我如何在 MVC/MVVM Windows 窗体应用程序中进行错误处理
我正在使用类似于 MVC 的模式构建一个应用程序。接下来的情况是：在模型的上下文中对关联存储库进行更改。如果更改引发异常，向用户呈现有关错误的信息的正确方法是什么？ 在我的程序的先前版本中，当我有 Spaguetti 代码组织（模型、视图、控制器重叠）时，启动一个消息框告诉用户错误并不奇怪，因为我几乎是从视图中执行所有操作。现在在这个新版本中，我想正确地做这些事情，所以我想在模型层中做任何有视觉表示的事情都是不好的。 前段时间我问捕获异常的正确方法是什么。我所指的具体点是将异常从内部代码扩展到上层，而不是在最上层捕获它们。几乎所有的回应都是这不是一个好的方法来处理异常（捕获并再次抛出以由负责的实体捕获），并且最好在最上层捕获。 所以我脑子里有这个冲突。我认为保持关注点分离以扩大规模是不可避免的，但这与之前的建议相冲突。 我该如何继续？
i'm building an application using a pattern similar to the MVC. The situation is the next: in the context of the model making changes to the associated repository. If the change throw an exception what is the correct way to present the information about the error to the user?
In the previous version of my program when i have spaguetti code organization (model, view, controller overlaped), launching a messagebox telling the user about the error wasn't weird because i was doing almost everything from the views. Now in this new version i want to do the things correctly, so i guess that is bad doing anything that has a visual representation in the model layer.
Some time ago i ask what is the correct way to capture exceptions. The specific point i was refering was to scale up exceptions from an inner code to an upper layer vs capture them in the most upper layer. Almost all the response were that isnt a good approach scale exceptions(capture and throwing again to be captured by a responsable entity), and is better to capture in the most upper layer.
So i have this conflict in my head. I was thinking that is inevitable to maintain the separation of concerns to scale up, but that is in conflict with those previous advices.
How can i proceed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种常见的模式是在现有模型中有一个通用的位置来放置错误。
实现此目的的一种简单方法是让您的模型类全部继承自具有
IEnumerable类型的属性或您选择的其他类型的属性的基模型类。 然后，在演示器中，您可以检查错误收集并根据需要进行显示。
至于异常冒泡，我使用的方法（几乎无论我正在构建什么类型的应用程序）都是仅在较低级别处理异常，如果您要执行一些特殊的日志记录（例如记录重要的局部变量），或者如果你可以做一些聪明的事情来处理这个例外。否则，就让它冒泡。
在演示者（或 Web 服务类或其他）之前的层，您可以捕获异常、执行常规日志记录并将它们包装（或替换为）“已清理”的异常。对于用户界面，您只需确保不泄露敏感数据，并在可能的情况下显示一条友好的消息。对于 Web 服务，您可以将这些转变为某种故障。等等。
最上层对冒泡异常不“负责”，它们只是负责确保这些异常不会以您不希望的形式显示给最终用户（或 Web 服务客户端或其他）。不希望他们……换句话说，你正在适当地“展示”他们。
请记住，关注点分离是您应该遵循的经验法则，而不是拥有一切的法令。就像有漏洞的抽象一样，也存在有漏洞的范式。做有意义的事，不要太担心。 :)
A common pattern is to have a generic place to put errors in your existing model.
One easy way to do this is to have your model classes all inherit from a base model class that has a property of type
IEnumerable<ErrorBase>, or some other type of your choosing.Then, in your presenter, you can check the error collection and display as necessary.
As far as having exceptions bubble up, the approach I use (almost regardless of what type of application I'm building) is to only handle exceptions at lower levels if you are going to do some special logging (like logging important local variables), or if you can do something intelligent with that exception. Otherwise, let it bubble.
At the layer right before your presenter (or web service class, or whatever), that's when you can capture your exceptions, do general logging, and wrap them (or replace them with) a "sanitized" exception. In the case of the UI, you just make sure you don't reveal sensitive data and perhaps display a friendly message if possible. For web services, you turn these into some kind of fault. Etc.
The upper most layers aren't "responsible" for the bubbled exceptions, they're simply responsible for making sure those don't show up to the end users (or web service client, or whatever) it a form you don't want them to... in other words, you're "presenting" them appropriately.
Remember, separation of concerns is a paradigm that you should follow as a rule of thumb, not an edict that owns all. Just like leaky abstractions, there are leaky paradigms. Do what makes sense and don't worry about it too much. :)