CRUD设置的Create,Uupdate和Delete部分(具有更复杂的业务规则)的最佳返回类型是什么？
我希望能够最大限度地减少线路上的来回,但我也希望为我的客户提供有关何时操作失败我的业务逻辑但在技术上有效的有意义的信息(因此它不是例外).
举个例子,CRUD用于Person类,它包含以下字段：FirstName,MiddleName LastName和Brith的Date.首先,最后和DOB是必需的,但中间则不是.
我应该如何将业务逻辑的失败传达给客户？ I.E. “您必须为FirstName指定一个值.”
>这是我应该扔的地方吗？
异常？ (感觉不像
一个例外情况,所以我想
不,但我可能是错的).
>我应该使用void和“out”参数吗？如果是这样,它应该是什么类型的？
>我应该使用对象返回类型并将数据放在那里以了解会发生什么？
>我完全错过了一些其他选择？
解决方法
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层进行提交.
