干净的架构-将输入验证逻辑放在哪里？ [英] Clean architecture - where to put input validation logic?

问题描述

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

Perhaps in the app I have a feature allowing users to send feedback using a form with some validation logic:

• 名称可以为空


• 反馈消息应至少包含5个字符

您将这些验证逻辑放在哪里，在域层作为业务逻辑还是在表示层作为UI逻辑？

Where would you put these validation logic, either in domain layer as business logic or in presentation layer as UI logic?

这些逻辑适用于所有应用程序（Android，iOS，Web）。请注意，我们已经进行了服务器端验证。

These logic are applied for all applications (android, iOS, web). Please note that we already had server side validation.

推荐答案

我认为许多开发人员都在 Presentation 层，特别是在 ViewModel / Presenter / Controller 层中（活动/片段/视图中的不是！ ）。我的方法是将该逻辑放在 Domain 层中。为什么？

I think many developers do that in Presentation layer, specifically in ViewModel/Presenter/Controller (not in Activity/Fragment/View!). My approach is to put that logic in Domain layer. Why?

• 是表示逻辑还是领域逻辑？呈现逻辑是您决定的映射渲染模型，渲染模型的格式，如何渲染，什么颜色，什么大小，哪个文本，它将在屏幕上停留多长时间等。验证是表示逻辑，为什么后端代码具有相同的验证控件？在我看来，验证是域逻辑。


• 为什么验证是域逻辑？谁决定用户名最多不能超过20个字符？业务规则决定。谁决定购物篮中最大物品的数量？业务规则决定。用户名的长度由业务决定，该规则适用于项目中的无处不在。 CreateProfile / UpdateProfile / Register等。都具有相同的max-20char-username规则。 该长度控制（验证）代码应驻留在域层中。


• 如果验证代码在域层中，流程将如何？用户单击视图中的按钮。 ViewModel / Presenter调用域层功能。域层功能验证输入数据。如果输入参数无效，则返回 ValidationException 及其解释。 ValidationException 将包含无效参数，验证类型失败的列表（minLength，maxLength，emailPatternMismatch等..），期望值（最大为 20个字符，等等。）。 ViewModel / Presenter / Controller 获取此 ValidationException ，这里我们有表示逻辑。现在，它决定要渲染什么，如何渲染。我们是呈现所有无效输入的错误还是仅呈现第一个无效输入的错误？应显示什么文本/颜色（基于ValidationException中的数据）？我们是否将错误呈现为popup / textView / tooltip？在做出所有演示决定并创建新模型之后，只需 View ！


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

• Is it presentation logic or domain logic? Presentation logic is something you decide "mapping render model", "format of render model", "how to render", "what color, what size, which text", "how long will it stay on screen" etc... If validation is presentation logic, why does backend code have same validation control? From my perspective, validation is Domain logic.
• Why validation is Domain logic? Who decides if username can be 20 char at max? Business rule decides. Who decides number of max items in shopping basket? Business rule decides. The length of username is decision of business, and that rule applies in everywhere in the project. CreateProfile/ UpdateProfile/ Register etc.. all have same max-20char-username rule. That length control (validation) code should reside in Domain layer.
• What is the flow if validation code is in Domain layer? User clicks button in View. ViewModel/Presenter calls domain layer function. Domain layer function validates input data. If there are invalid input parameters, it returns ValidationException with explanation. ValidationException will contain list of invalid parameters, type of validation they failed (minLength, maxLength, emailPatternMismatch etc..), what is expected (20 char at max etc..). ViewModel/Presenter/Controller gets this ValidationException and here we have Presentation logic. Now it decides what to render, how to render. Do we render error of all invalid inputs or only first invalid input? What text/color should be shown (based on data in ValidationException) ? Do we render error as popup/textView/tooltip? After all presentation decisions are made and new model is created, View just! renders using that model.
• Another point is, in Domain layer, where should be validation code? In UseCase functions or in Models (why not) itself? IMHO, there should be Stateless Generic Interface/Class that has generic validation logics. And after that point, each UseCase class can implement ValidationInterface or inject it as Class object. If multiple UseCases need same validation, validation control logic will be duplicated. What happens if we put validation logic in Model itself? Model would implement ValidationInterface (which has stateless pure functions only!) and have fun validate():ValidationOutcome function. I don't think it is problem to put validation logic of Business Model in itself. All UseCases would call model.validate() only. There is dependency between Model and ValidationOutcome.

这篇关于干净的架构-将输入验证逻辑放在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！