InventorySample数据验证深度解析：ValidationConstraint与Model绑定校验的完整实现

InventorySample数据验证深度解析ValidationConstraint与Model绑定校验的完整实现【免费下载链接】InventorySampleSample UWP application for LOB scenarios项目地址: https://gitcode.com/gh_mirrors/in/InventorySampleInventorySample 是一个面向企业级LOB场景的 UWP 示例应用本文带你完整拆解它的数据验证机制如何通过ValidationConstraint约束类与 MVVM 模式的 Model 绑定校验在保存前拦截非法数据保障数据完整性。无论你是 UWP 新手还是 MVVM 实践者都能在 10 分钟内看懂这套开箱即用的校验体系。上图是 InventorySample 的客户编辑界面右侧表单中的每个输入框在点击 Save 之前都会经过一套约束校验任何必填项缺失都会被立即拦截并提示。为什么 UWP 应用必须做数据验证任何接受用户输入的应用都必须先验证数据才能入库原因有三️数据完整性防止空姓名、非法数量等脏数据写入数据库⚡提前失败在保存前就报错而不是等到数据库层才抛异常业务规则落地如折扣不能大于小计金额这类规则代码化后不可绕过。在 MVVM 架构中验证逻辑应该放在ViewModel层执行、作用于Model数据并向 View 反馈错误——这正是 InventorySample 的设计思路。核心接口 IValidationConstraint一条规则 一个判定函数 一句错误提示整个验证体系的地基是 ValidationConstraint.cs 中的接口它非常简洁public interface IValidationConstraintT { FuncT, bool Validate { get; } // 校验函数输入Model返回是否通过 string Message { get; } // 失败时的提示文案 }项目已内置7 个现成的约束类覆盖绝大多数业务场景约束类用途提示文案RequiredConstraintT字段必填属性 {名称} 不能为空RequiredGreaterThanZeroConstraintT必填且大于零属性 {名称} 不能为空PositiveConstraintT数值必须 ≥ 0属性 {名称} 必须为正数NonZeroConstraintT数值不能为零属性 {名称} 不能为零GreaterThanConstraintT必须大于指定值属性 {名称} 必须大于 {值}NonGreaterThanConstraintT不能超过指定值属性 {名称} 不能大于 {值}LessThanConstraintT必须小于指定值属性 {名称} 必须小于 {值}所有约束都是泛型T同一个约束类可以作用于任意 Model数值型约束内部用Double.TryParse安全解析解析失败时不会抛异常而是按宽松策略放行——对新手很友好。GenericDetailsViewModel 基类所有详情页免费获得的保存前校验这套校验不是每个页面各自实现的而是统一收敛在详情页基类中。如下面的 ViewModel 继承体系图所示所有*DetailsViewModel都继承自GenericDetailsViewModelTModel在 GenericDetailsViewModel.cs 中保存命令的流程是用户点击Save→ 触发SaveCommand先调用Validate(EditableItem)逐条执行约束任一失败立即返回Result.Error校验通过才执行SaveAsync()真正写库校验失败则弹出对话框Validation Error — {错误提示}。请修正后重试。子 ViewModel 要接入这套机制只需重写一个虚方法GetValidationConstraints(model)返回约束列表即可——这就是模板方法模式的经典应用。实战案例三种实体的真实校验规则客户8 个必填字段RequiredConstraintCustomerDetailsViewModel.cs 为CustomerModel声明了姓名、邮箱、地址、城市、地区、邮编、国家共 8 条必填约束。客户详情页就是下图中的编辑面板任何必填项留空都无法保存订单条件校验按订单状态动态追加规则OrderDetailsViewModel.cs 展示了更高级的用法——条件约束任何订单都必须指定客户RequiredGreaterThanZeroConstraint校验CustomerID当订单状态 0已提交时才追加付款方式必填状态再进一步 1已发货时才追加承运商必填。约束列表是动态yield return生成的所以同一套机制能表达分阶段业务规则无需 if-else 散落各处。订单明细数量与折扣的组合拳OrderItemDetailsViewModel.cs 是约束组合最丰富的示例对同一属性叠加多条规则Quantity数量不为零 必须为正 必须小于 100Discount折扣必须为正 不能大于 Subtotal小计。注意最后一条NonGreaterThanConstraint的上限值直接取自当前 Model 的model.Subtotal属性说明约束的边界值不是硬编码的而是与业务数据实时联动。Result 结果对象验证结果与对话框的衔接校验的返回值统一使用 Result.cs 中的Result类IsOk标记成败Message/Description分别承载标题与详情。这种无异常的错误传递方式让 ViewModel 逻辑干净、可测试也与项目中服务层的数据访问风格保持一致。小结这套方案好在哪优点说明单一接口一条约束 一个函数 一句文案5 分钟即可上手零重复基类统一执行每个详情页只写规则、不写流程泛型复用7 个约束类适用于所有 Model规则内聚校验逻辑随 ViewModel 定义随业务演进 关键文件速查约束接口与 7 个实现ValidationConstraint.cs保存前校验基类GenericDetailsViewModel.cs官方验证机制文档Validation.md数据模型定义Models/理解了IValidationConstraintGenericDetailsViewModel的组合你就掌握了 InventorySample 数据验证的完整闭环定义约束 → 重写方法 → 保存自动校验 → 失败弹窗提示。把这套模式搬进你自己的 MVVM 项目数据质量就有了第一道坚实防线。【免费下载链接】InventorySampleSample UWP application for LOB scenarios项目地址: https://gitcode.com/gh_mirrors/in/InventorySample创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考