architecture - 在哪里验证程序中的用户输入？

Question

假设我必须为一家小型诊所公司实现一个程序，允许其用户(即医生)安排咨询、记录客户病史等。因此，这可能是标准的 3 层应用程序: 表示、 Controller 和数据层(将连接到数据库)。

我看到了 3 种可能性:

1. 我的第一个想法是将验证代码放在领域层中。但是我觉得我可能会想对 A 类进行检查，然后对使用 A 的 B 进行相同的检查，然后对使用 B 的 C 进行相同的检查，等等。另一方面，它很好，因为它很容易单元化-测试验证逻辑。

2. 还有第二种观点认为，验证用户输入的最佳位置是尽快，即可能在表示层(或 Controller )上。总的来说，这似乎是个好主意。如果在 Controller 上，单元测试可能也很容易。它还允许人们切换 View 或数据层，并且仍然一切正常。

3. 尝试将最有效的逻辑放在数据库本身上。这似乎是个好主意，因为它强制没有数据破坏数据库。我看到的问题是，如果我想使用不同的数据存储库，我将不得不为新数据存储库再次进行数据验证逻辑。例如，在领域层有这种逻辑就不会出现这个问题。

您通常如何解决这个问题？

Answer 1

正如您所注意到的，验证数据的地方不止一个。

还有几个级别的验证:

1. 正确的格式和类型；存在所有必需的值(例如，如果需要出生日期，请确保它出现并且是日期类型；如果它是字符串，请确保它符合预期的格式，例如“yyyy-MM-dd”)
2. 1 级加上“业务正确性”:完成的交易符合您的业务规则(例如，“出生日期必须至少比今天早十八年”)。

有一种观点认为您应该考虑所有这些:

1. 在客户端上进行验证以确保为用户提供最佳体验。不要让他们等待往返服务器才能发现问题。放置一个 JavaScript 验证，立即告诉他们 1 级有效性。
2. 在服务器端再次验证，因为您的服务层前面可能没有用户界面。绑定(bind)并验证进入您的服务层的所有值。
3. 执行所有 2 级验证作为服务层事务的一部分。确保从业务角度来看输入是正确的。
4. 如果数据库由多个应用程序共享，将业务逻辑放入约束、存储过程和触发器中以确保数据完整性。

我认为这些不应该是“非此即彼”的决定。