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

Question

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

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

基本规则如下：

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

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

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

我现在正在构建验证，但不确定在我的应用程序中哪一层应该发生钙化。我不相信它在UI上，因为我需要在我的ASP.Net项目上复制验证规则……也许我的WinForms前端。

我认为它应该在业务逻辑中，因为它有业务规则。因此，我打算创建一个名为" 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)。我认为这并不令人担忧，因为这都是向业务层和数据层透露的。

Answer 1

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

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

Answer 2

当一个对象有可能变得不一致时，我总是试图创建障碍来防止这种情况，越早越好。

早期

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

坚定地

在业务中，尝试将这些规则建模为一次强制执行的不变量，而不是您可能需要多次执行的验证。换句话说，请确保您的业务对象是always valid。

• 在创建时强制执行不变量(在构造函数或工厂中)，并尽可能使对象成为不可变的Value Objects。您示例中的PersonAssignment就是一个很好的候选者。值对象是简单的结构，你永远不会去修改它们，你只需要用另一个替换它们，所以保持它们的一致性是小菜一碟。
• 对于你不能明智地使其完全不可变的对象(如Sprint)，你仍然可以过滤掉对某些字段的不必要的修改。例如，修改属性StartDate和EndDate的设置器，使其不接受项目范围之外的日期。
• 有时，与状态更改相关联的业务规则更为复杂，并且涉及许多条件。我发现在单个方法中定义业务操作并在其中合并所有不变检查总是更好，而不是让您的实体处于崩溃状态，然后尝试在事后进行验证。

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