应用程序级验证逻辑是否足以维护数据一致性

Question

在我们的项目中，我们的用户可以拥有多张信用卡。他一次只应该有一个默认值（布尔值：true）。从当前的UI和当前的应用程序逻辑来看，不可能有多个。但是，如果您打开一个rails控制台，您可以更改并拥有多个控制台。

编写一些额外的代码是一个好习惯，它会检查用户的所有信用卡记录，将默认信用卡的数量限制为模型级别的一个？或者这是否过度工程？

Answer 1

我会在模型中禁止它，特别是如果有两个默认值会破坏它。这样一来，未来的程序员就会知道这很糟糕，如果他没有注意到并且无论如何都会这样做，他会被告知。

Answer 2

在我看来，编写额外的验证是一种很好的做法。模型是与持久业务对象相关的代码的位置（依赖于Rails约定）。如果业务对象user具有collection of credit cards且此集合具有一些业务规则，则应在模型中对其进行描述。

一些论点：

• 想象一下：未来两年你的首席执行官可以说＆＃34;嘿，伙计们，我们必须建立现代用户界面，抛弃当前的erb模板并让我们使用X.＆＃34;而将被聘用为X的前端人员可能会错过信用卡的业务规则。
• 互联网是一个非常可怕的地方，许多黑客正在做黑暗的事情。特别是在Google上通过关键字＆＃34;信用卡收集＆＃34;找到的网站上。他们可以发送一些手动准备的HTTP请求来制动你的系统。你永远不应该把你的安全放在HTML temlpates或JS客户端应用程序上。