0

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

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

基本规则是：

一个人被分配到一个 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）。我认为这不必担心，因为这一切都交给了业务和数据层。

4

2 回答 2

0

除非您必须这样做，否则我不会担心数据库命中。在你的架构正确之后，有很多方法可以优化它。一个好的缓存层将使大多数缓存层消失，如果没有，您总是可以编写一个单独的域对象，即“SprintValidation”对象，以包含验证它所需的所有数据。

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

于 2013-08-19T13:40:37.317 回答
0

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

早期的

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

牢牢

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

  • 在创建时（在构造函数或工厂中）强制执行不变量，并尽可能使您的对象成为不可变的值对象。您的示例中的 PersonAssignment 是一个很好的选择。值对象是您从不费心修改的简单结构，您只需将它们替换为另一个，因此保持它们始终一致是小菜一碟。

  • 对于您无法明智地使其完全不可变的对象（例如 Sprint），您仍然可以过滤掉对某些字段的不需要的修改。例如，将属性 StartDate 和 EndDate 的设置器修改为不接受项目范围之外的日期。

  • 有时，与状态更改相关的业务规则更复杂，并且涉及许多条件。我发现在单一方法中定义业务操作并在那里合并所有不变检查总是更好，而不是让您的实体进入损坏状态并在之后尝试验证它。

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

于 2013-08-19T14:12:46.800 回答