EF架构~FluentValidation实体检验与实体分离了

简介:

在MVC,EF,LINQ环境里,我们经常会用到DataModel(DO)和ViewModel(VO),可能对于它们的属性校验我们会采用特性的方式,当然这很直观,就连微软的DEMO也是如些,一般是这样的代码

        /// <summary>
        /// 机构ID
        /// </summary>
        [DisplayName("机构ID")]
        public int AgentId { get; set; }
        /// <summary>
        /// 机构名称
        /// </summary>
        [DisplayName("机构名称")]
        [MaxLength(128)]
        public string AgentName { get; set; }
        /// <summary>
        /// 机构负责人
        /// </summary>
        [DisplayName("机构负责人")]
        [MaxLength(128)]
        public string AgentUser { get; set; }

而这种设计方式给我们以后的维护带来很多问题,具体大叔总结一下:

  1. 与数据实体混在一起,不利用扩展,更新实体你加的特性可能会丢失
  2. 如果有多个VO,那么你需要把它加到具体的VO上,因为DO的语义可能不太明确
  3. 不方便迁移,它与ModelState耦合太高
  4. 从面向对象的角度来看,它的职责太单一,引起变因太多

综上所述,FluentValidation就诞生了!

nuget上去安装它:install-package FluentValidation

你的一个实体类,可以添加多个检验类,这相当于可以有多种检验类去装饰一个实体类,我觉得挺好!

   public class CreateUserEventValidator : AbstractValidator<CreateUserEvent>
    {
        public CreateUserEventValidator()
        {
            RuleFor(command => command.UserName).NotEmpty().Length(5, 20).WithMessage("用户名升序为5-20字符!");
            RuleFor(command => command.Email).NotEmpty().EmailAddress().WithMessage("不是有效的Email!");
            RuleFor(command => command.BirthDay).NotEmpty().Must(i => i < DateTime.Now).WithMessage("你的年紀太小了!");
        }
    }

使用时,可以通过IsValid,Errors等属性拿到你需要的信息,当然,你也可以把它在命令事件,领域事件上用一下,比如做个验证的装饰器,哪些处理程序要用校验,就通过这个装饰器装饰一下就行了,挺优雅!

   //验证-装饰器
   BusManager.Instance.Subscribe(new ValidatorDecorator<CreateUserEvent>(
new UserEventHandler(),
new CreateUserEventValidator())); //日志-装饰器 BusManager.Instance.Subscribe(new LoggerDecorator<CreateUserEvent>(new UserEventHandler())); BusManager.Instance.Publish(new CreateUserEvent { UserName = "占占大师5个字" });

装饰器要求你转一个要被装饰的对象和一个装饰器,就可以了。

    /// <summary>
    /// 验证装饰器
    /// </summary>
    /// <typeparam name="TEvent"></typeparam>
    [Serializable]
    public class ValidatorDecorator<TEvent>
       : IBusHandler<TEvent>
        where TEvent : IBusData
    {
        /// <summary>
        /// 要被装饰的处理程序
        /// </summary>
        private readonly IBusHandler<TEvent> _inner;
        /// <summary>
        /// 校验装饰器集合
        /// </summary>
        private readonly IValidator<TEvent>[] _validators;

        /// <summary>
        /// 初始化
        /// </summary>
        /// <param name="inner">要被装饰的处理程序</param>
        /// <param name="validators">装饰器</param>
        public ValidatorDecorator(IBusHandler<TEvent> inner, params IValidator<TEvent>[] validators)
        {
            _inner = inner;
            _validators = validators;
        }
        public void Handle(TEvent evt)
        {
            var failures = _validators
                           .Select(v => v.Validate(evt))
                           .SelectMany(result => result.Errors)
                           .Where(error => error != null)
                           .ToList();

            if (failures.Any())
            {
                throw new ValidationException("实体校验失败", failures);
            }

            _inner.Handle(evt);
        }
    }

对于一种知识的学习与理解是需要一些理论基础的,大家可以多看看设计模块,算法导论,.netCLR等书籍!

感谢各位的阅读!

本文转自博客园张占岭(仓储大叔)的博客,原文链接:EF架构~FluentValidation实体检验与实体分离了,如需转载请自行联系原博主。

目录
相关文章
|
6月前
|
存储 分布式计算 并行计算
计算存储分离架构
计算存储分离架构
|
存储 Java API
阿里高级技术专家谈开源DDD框架:COLA4.1,分离架构和组件(下)
阿里高级技术专家谈开源DDD框架:COLA4.1,分离架构和组件(下)
8516 1
阿里高级技术专家谈开源DDD框架:COLA4.1,分离架构和组件(下)
|
搜索推荐 前端开发 架构师
阿里高级技术专家谈开源DDD框架:COLA4.0,分离架构和组件(上)
阿里高级技术专家谈开源DDD框架:COLA4.0,分离架构和组件(上)
2293 0
阿里高级技术专家谈开源DDD框架:COLA4.0,分离架构和组件(上)
|
3月前
|
存储 Cloud Native 数据处理
Flink 2.0 状态管理存算分离架构演进
本文整理自阿里云智能 Flink 存储引擎团队负责人梅源在 Flink Forward Asia 2023 的分享,梅源结合阿里内部的实践,分享了状态管理的演进和 Flink 2.0 存算分离架构的选型。
837 0
Flink 2.0 状态管理存算分离架构演进
|
3月前
|
数据可视化 数据挖掘 数据管理
架构之争:数用一体VS数用分离,谁才是永远滴神
架构之争:数用一体VS数用分离,谁才是永远滴神
|
8月前
|
存储 缓存 Apache
Apache Doris 巨大飞跃:存算分离新架构
Apache Doris 巨大飞跃:全新的存算分离架构正式推出,SeiectDB 未来将贡献至 Apache Doris 社区
Apache Doris 巨大飞跃:存算分离新架构
|
11月前
|
存储 SQL 数据可视化
「数据架构」什么是实体关系图(ERD)?
「数据架构」什么是实体关系图(ERD)?
|
存储 固态存储 Cloud Native
【Paper Reading】PolarDB计算存储分离架构性能优化之路
本篇论文收录在 VLDB 2022,介绍了云原生数据库PolarDB在计算存储分离架构下遇到的性能挑战,分析了云存储相对于传统本地存储的工作特性差异及其根因,讨论了将各类存储引擎部署至云存储上时所会遇到的问题挑战,并提出了统一的优化框架 CloudJump。最后通过实验证明优化框架CloudJump适用于PolarDB,也适用于 RocksDB。
【Paper Reading】PolarDB计算存储分离架构性能优化之路
|
存储 弹性计算
|
存储 关系型数据库 分布式数据库
Paper Reading 预告 | 揭秘 PolarDB 计算存储分离架构性能优化之路
12月29日 19:00 锁定「阿里云数据库视频号」揭秘PolarDB计算存储分离架构性能优化之路
Paper Reading 预告 | 揭秘 PolarDB 计算存储分离架构性能优化之路