验证逻辑应在哪里实施? [英] Where should validation logic be implemented?

问题描述

在开发接口(合同)及其具体实现时，无论是数据模型还是存储库，我都发现自己在质疑验证逻辑应该去哪里.我的一部分(倾向于胜出)说，类本身应该负责它自己的验证(字符串最大长度，日期缓冲区等)，但是我的另一部分说，这应该移到存储库中，因为在持久性存储上，这些值可以根据您的存储库实现而更改.

When developing my interfaces (contracts) and the concrete implementations of them, both the data models as well as repositories, I find myself questioning where the validation logic should go. Part of me (which tends to win out) says that the class itself should be responsible for it's own validation (string max length, date buffers, etc), but the other part of me says this should be moved out to the repository because depending upon the persistence store, these values could change based on your repository implementation.

我认为有一些验证必须在类级别完成，并且认为它应该保持在一起，即使存储库也不能更改，这就是为什么我倾向于将其保留在类中.

I think there is some validation that MUST be done at the class level and think it should probably be kept together and not change even if the repository does, which is why I tend to keep it in the class.

我全力以赴进行UI验证，但这还远远不够，因为可以绕过很多UI验证.

I am all about putting in UI validation but this is never enough since much of the UI validation can be bypassed.

很好奇人们的想法及其背后的原因.

Curious what people think and the reasoning behind it.

推荐答案

验证规则应以一种抽象的方式在类级别上定义，可以同时1)在类的本机环境中运行2)呈现为其他规则依赖的环境，例如根据需要的UI脚本或存储库过程.

Validation rules should be defined at the class level in an abstract fashion that can both 1) be run in the class's native environment 2) be rendered as rules for other dependent environments, such as UI scripting or repository procedures, as needed.

这使您可以将逻辑集中在类中的位置，以及在UI中以及其他位置的辅助验证-易于维护，因为它是从类派生的，而不是处于分离位置的分离逻辑.全方位的胜利.

This gets you the logic centralized where it should be, in the class, and ancillary validation in the UI and wherever else -- easily maintainable since it's derived from the class rather than being detached logic living in a disconnected location. All-around win.

这篇关于验证逻辑应在哪里实施?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！