c# – CRUD类库设计,返回有关业务逻辑失败的有用消息,这并非例外

1.Is this where I should be throwing exceptions? (it does not feel like an exceptional case,so I think not but I could be wrong).

就个人而言,我觉得你应该返回一个带有结果的对象以及任何验证错误,并且不会抛出数据验证的异常,无论是由于缺少信息(格式验证)还是业务逻辑验证.但是,我确实建议为与数据本身无关的错误抛出异常 – 即：如果数据库提交失败并带有有效数据等.

我在这里的想法是,验证失败不是“特殊情况”.我个人认为,只要没有输入足够的/正确的/ etc数据,任何用户都会搞砸的东西也不例外 – 这是标准做法,应该由API直接处理.

与用户正在做的事情无关的事情(即：网络问题,服务器问题等)是特殊情况,并且需要例外.

2.Should I use void and an “out” parameter? If so,what type should it be?

3.Should I use an object return type and put data in there about what happens?

我个人更喜欢第三种选择. “out”参数不是很有意义.此外,您还希望从此调用返回多个状态信息 – 您需要返回足够的信息以将相应的属性标记为无效,以及任何完整的操作范围信息.

这可能需要一个至少包含提交状态(成功/失败格式/失败的业务逻辑/等)的类,属性的映射列表 – >错误(即：IDataErrorInfo样式信息),以及可能是一个与特定属性无关的错误列表,而是处理整个操作的业务逻辑或建议的属性值的组合.

4.Some other option that I’ve missed completely?

我非常喜欢的另一个选项是在业务处理层的单独程序集中进行验证.这允许您在客户端重用验证逻辑.

关于这一点的好处是,您可以显着简化和减少网络流量.客户端可以预先验证信息,只有在有效的情况下才能通过网络发送数据.

服务器可以接收好的数据,并重新验证它,并返回一个提交结果.我相信这应该至少有三个响应 – 成功,由于业务逻辑而失败,或者由于格式化而失败.这给了安全性(您不必信任客户端),并向客户端提供有关未正确处理的信息,但避免传递来自客户端>服务器的错误信息以及来自服务器>客户端的验证信息,这样可以大大减少流量.

然后,验证层可以(安全地)将信息发送到CRUD层进行提交.