coding-style - 整洁的架构——在哪里放置输入验证逻辑？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

1年前关闭。




Improve this question




也许在应用程序中，我有一个功能允许用户使用带有一些验证逻辑的表单发送反馈:

名称可以为空

反馈信息至少应为 5 个字符

您会将这些验证逻辑放在哪里，或者在 domain layer 中？作为业务逻辑或在 presentation layer作为 UI 逻辑？

这些逻辑适用于所有应用程序(android、iOS、web)。请注意，我们已经进行了服务器端验证。

Answer 1

我认为许多开发人员在 Presentation 中都这样做了。层，特别是在 ViewModel/Presenter/Controller ( 不是 在 Activity/Fragment/View! 中)。我的方法是把这个逻辑放在 Domain层。为什么？

是表示逻辑还是领域逻辑？表示逻辑是你决定“映射渲染模型”、“渲染模型的格式”、“如何渲染”、“什么颜色、什么大小、什么文本”、“它会在屏幕上停留多长时间”等等......如果验证是表示逻辑，为什么后端代码具有相同的验证控制？从我的角度来看，验证是域逻辑 .

为什么验证是域逻辑？谁决定用户名是否最多可以是 20 个字符？业务规则决定。谁决定购物篮中的最大商品数量？业务规则决定。用户名的长度由业务决定，该规则适用于项目中的任何地方。 CreateProfile/UpdateProfile/Register 等都具有相同的 max-20char-username 规则。 该长度控制(验证)代码应该驻留在域层中。

如果验证码在域层，流程是什么？用户单击 View 中的按钮。 ViewModel/Presenter 调用领域层函数。域层函数验证输入数据。如果输入参数无效，则返回ValidationException有解释。 ValidationException将包含无效参数列表、它们失败的验证类型(minLength、maxLength、emailPatternMismatch 等)、预期内容(最大 20 个字符等)。 ViewModel/Presenter/Controller得到这个ValidationException在这里我们有表示逻辑。现在它决定渲染什么，如何渲染 .我们是渲染所有无效输入的错误还是只渲染第一个无效输入？应该显示什么文本/颜色(基于 ValidationException 中的数据)？我们是否将错误呈现为弹出/ TextView /工具提示？在做出所有演示决定并创建新模型后，View只是!使用该模型进行渲染。

还有一点是，在领域层，验证码应该放在哪里？在 UseCase 函数或模型(为什么不)本身中？恕我直言，应该有具有通用验证逻辑的无状态通用接口(interface)/类。在那之后，每个 UseCase 类都可以实现 ValidationInterface 或将其作为 Class 对象注入(inject)。如果多个 UseCases 需要相同的验证，验证控制逻辑将被复​​制。如果我们将验证逻辑放入模型本身会发生什么？模型将实现 ValidationInterface(仅具有无状态纯函数!)并具有 fun validate():ValidationOutcome功能。我不认为将业务模型的验证逻辑放在自身中是有问题的。所有用例都会调用 model.validate()只要。 Model 和 ValidationOutcome 之间存在依赖关系。