gpt4 book ai didi

c# - 关于 GUI 与逻辑类集成方式的一个非常基本的问题

转载 作者:行者123 更新时间:2023-11-30 21:23:44 25 4
gpt4 key购买 nike

假设我有一个巨大的输入表单,它当然代表类。我需要将此输入加载到类的实例中。这个输入显然包含(一些非常复杂的验证)检查,显然逻辑层已经包含那些输入验证。问题是我在用 gui 做什么。

我是否应该以一种非常丑陋的方式在 GUI 中重写所有这些验证?

或者我应该在逻辑层中编写一些静态方法,在 gui 和逻辑层中使用这些方法,但仍然创建 self 验证的重复(首先 gui 验证自身,然后逻辑验证什么发送给它)

或者我应该假设 gui 没问题,用 try block 包围使用逻辑层的相关代码,然后,如果抛出异常,通知用户某些事情不对(不给他机会)知道它是什么)

或者我应该公开异常,以这种方式向他公开他可能不理解的参数、类和命名空间名称。

或者我应该为每个错误创建一个特殊的异常类,这样就可以准确地告知用户问题是什么,但可能会产生数百个可能的异常

或者我应该将其分离为一般异常,其中每个人都包含枚举描述错误的确切内容,然后捕获这些异常,并通过检查枚举告知用户究竟是什么问题,但通过不必要的捕获使应用程序变得更重总是有异常。

或者我应该(有人向我提供了这个,这不是我的主意,不要对我大喊大叫 :D)来验证逻辑层中的输入,并且只在 gui 中检查它(似乎是我绝对可怕的解决方案 :D)

还有更重要的问题 - 我应该在哪里学习这些东西?通常我的直觉很好,但我不想不必要地发明轮子..(我很确定已经有关于你每天轰炸的这些基本事情的约定)。

非常感谢!

最佳答案

当然,您应该验证用户输入。如果输入和验证逻辑像你说的那样复杂,那么在 GUI 中验证输入就更重要了,这种方式让用户清楚地知道预期值是什么,如果有任何错误, 它们是什么。如果您能建议如何修复这些错误,可加分!

它确实无法帮助用户查看异常和异常详细信息——因此请尽量避免这种情况。

此外,由于您在 GUI 中处理输入验证,错误的输入是一种预料之中的情况,并不是真正的异常,因此使用 Exceptions 不一定是个好主意。最好使用一个简单的 IsValid() 方法来检查某些内容是否有效。我始终遵循“异常(exception)情况适用于特殊情况”的规则。

因此,如果您接受在 GUI 中进行验证是一件好事,那么下一个问题是:怎么做?

你说你已经有很多验证,但听起来你的验证逻辑并不单独可用。我一直认为有用的一种做法是将验证代码与其他业务逻辑分开。这允许您在适当的地方重新使用验证逻辑,在这种情况下,将允许您在业务对象和 GUI 之间共享相同的验证逻辑。显然,有许多设计方法和框架可以做到这一点,但基本原则是“关注点分离”——保持验证逻辑独立,并使其可供使用。当您说“在逻辑层中编写一些静态方法,在图形用户界面和逻辑层中使用这些方法”时,您似乎在沿着相同的思路思考,这是一种被证明有效的方法。

只是为了清楚起见——我并不是建议您将验证逻辑放在 GUI 本身中。相反,让验证逻辑可供 GUI 使用。唯一应该在 GUI 中的验证部分是从用户那里获取输入(提交验证)的部分和显示验证结果的部分(向用户)。

编辑:

我不想听上去像是在为某种特定的设计哲学做托儿,但最近我一直在使用领域驱动设计原则做更多的工作。我发现它工作得很好,它解决了您提出的许多问题。关于 SO 的一些问题提供了有关它是什么以及某些资源在哪里的更多详细信息:

https://stackoverflow.com/questions/1353742/domain-driven-design-ddd-readings
What is domain driven design?

此外,请阅读此处:http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx

编辑 2:

还有一个有用的(和相关的)阅读:Business Objects, Validation And Exceptions

关于c# - 关于 GUI 与逻辑类集成方式的一个非常基本的问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1581468/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com