应用程序设计-验证和效率

本文关键字：效率 验证 程序设计 应用 | 更新日期: 2023-09-27 18:28:12

我有一个ASP.Net应用程序，它有很多关于对象是否可以提交到数据库的业务规则。

在基本层面上，一个人是sprint的一部分，sprint是项目的一部分。

基本规则是：

一个人被分配到一个sprint，但可能不是整个sprint的持续时间（有开始和结束日期）。因此，当他们分配人员时，他的开始日期和结束日期必须介于（包括）冲刺的开始日期和终止日期之间。

一个项目可以有许多sprint，但没有一个可以在项目开始/结束日期之外。

我的解决方案包括UI项目、服务层、业务层和数据访问层。

我现在正在进行验证，但不确定在我的应用程序中应该在什么级别进行校准。我不相信它在UI上，因为我需要在我的ASP.Net项目上复制验证规则。。。也许是我的WinForms前端。。。

我认为它应该符合商业逻辑，因为它有商业规则。因此，我打算创建一个名为"Validations"的类，对于存储到数据库中的每个业务对象，我的Validations中都有一个名"IsObjectOK"的方法，接受我想要验证的对象类型，并返回一个错误列表。

因此：

public List<String> IsObjectOK(SprintDto source)
{
    // Do validations, and return list of errors, or NULL if none
}

验证规则的一个例子可能是：

var Project = BusinessLayer.GetProject(source.ProjectId);
// check if Start/End dates fall between Project.Start and Project.End dates

如果出现问题，请将其添加到错误列表中。

这似乎是一个好办法。我正在寻找关于我处理验证的方法的确认，以及任何提示和技巧？我应该不担心数据库命中吗？我的意思是，对于sprint，我可能需要验证大约6或7个"规则"，所有这些规则都可能从不同的表中获取数据。因此，对于一次保存，这就是7个数据库查询（加上连接开销）。（SQL Server 2012）。我认为这并不令人担忧，因为这一切都是向业务层和数据层透露的。

应用程序设计-验证和效率

除非迫不得已，否则我不会担心数据库的命中率。有很多方法可以优化。之后，您可以正确地构建架构。一个好的缓存层会让大部分数据消失，如果没有，你可以总是写一个单独的域对象，即"SprintValidation"对象，以包含验证它所需的所有数据。

在意识到这是一个问题之前，不要从牺牲体系结构的性能开始。

当一个对象可能变得不一致时，我总是尽可能早、尽可能坚定地创建障碍来防止这种情况的发生。

早期

理想情况下，处于非相干状态的对象甚至不应该到达UI之上的层。创建或修改Sprint时，通常可以在客户端轻松检查日期间隔。用户会很感激关于哪里出了问题或不可能（例如灰色按钮）的即时反馈，双重保险总是很好的。然而，对于更复杂的验证，这可能是不可行的。

坚定

在业务中，尝试将这些规则建模为执行一次的不变量，而不是您可能需要执行多次的validation。换句话说，请确保您的业务对象始终有效。

  • 在创建时（在构造函数或工厂中）强制执行不变量，并尽可能使对象成为不可变的Value对象。示例中的PersonAssignment就是一个很好的候选者。值对象是一种简单的结构，你从不需要修改，只需要用另一个来替换它们，所以保持它们始终一致是小菜一碟。

  • 对于不能合理地使其完全不可变的对象（如Sprint），您仍然可以过滤掉对某些字段的不必要修改。例如，修改属性StartDate和EndDate的setter，使其不接受超出Project范围的日期。

  • 有时，与状态更改相关联的业务规则更为复杂，并且涉及许多条件。我发现，最好用一个方法定义业务操作，并在那里包含所有不变的检查，而不是让你的实体处于崩溃状态，然后尝试验证它。

简言之：将修改的机会缩小到几个地方，并毫不犹豫地在那里执行严格的执行，这样你就可以依靠信心而不是怀疑。

相关文章：