Lind.DDD~实体属性变更追踪器的实现

【Lind.DDD~实体属性变更追踪器的实现】的更多相关文章

Lind.DDD~实体属性变更追踪器的实现

回到目录看着这个标题很复杂,大叔把它拆开说一下,实体属性-变更-追踪器,把它拆成三部分大家看起来就容易懂一些了,实体属性:领域实体里有自己的属性,属性有getter,setter块,用来返回和设置属性的内容;变更:当前属性为赋值时,我们对它进行监视;追踪器:对变量的内容进行处理.好了,我们回到Lind.DDD框架中,在框架里有领域实体基类EntityBase,这个类是所有实体的基类,它公开了一些属性和方法,我们对这个基类进行一些设置,让所有子类都继承它,享用它. 1 属性变更追踪接口和它的事件…

Lind.DDD敏捷领域驱动框架~介绍

回到占占推荐博客索引最近觉得自己的框架过于复杂,在实现开发使用中有些不爽,自己的朋友们也经常和我说,框架太麻烦了,要引用的类库太多:之前架构之所以这样设计,完全出于对职责分离和代码附复用的考虑,主要参考了微软的DDD大作<N_LayerAPP>这个项目,而在这几年的项目开发用,也尝到了这种职责分享框架的甜头,但在最近的开发中,也看到了其它框架的出现,如<ABP>项目,它主张简单框架,敏捷开发,在项目引用上将核心类库和持久层进行抽象分离,复用在各位领域项目之中,这在项目整个感觉上更…

Lind.DDD.Aspects通过Plugins实现方法的动态拦截~Lind里的AOP

回到目录 .Net MVC之所以发展的如些之好,一个很重要原因就是它公开了一组AOP的过滤器,即使用这些过滤器可以方便的拦截controller里的action,并注入我们自己的代码逻辑,向全局的异常记录,用户授权,Url授权,操作行为记录等,这一大批Lind的基本组件都是实现MVC和API的过滤实现的,使用这些过滤让我们不用去像HttpModule和HttpHandler那样,还要在Config里配置注入点,让程序员在开发方式上感觉很舒服,维护成功很低! 本文主要内容点 Lind.DDD里的方…

Lind.DDD.Domain.IOwnerBehavor对实体的意义

回到目录对于Lind.DDD架构,我之前写了不少文章,对于它的Domain模式也介绍了不少,像之前的IEntity,ILogicDeleteBehavor,IModifyBehavor,IStatusBehavor和ISortBehavor都有自己的功能,只要实体实现对外的接口,就具有了某种特性或者某种功能,而今天主要说一下拥有者接口,IOwnerBehavor,它主要用在管理系统的实体中,如一个员工资产表,当这个员工离职后,它对应资产将被进行转移,转移到一个新的用户身上,而这个用户就是这个资…

Lind.DDD.Domain领域模型介绍

回到目录 Lind.DDD.Domain位于Lind.DDD核心项目中,它主要面向领域实体而设计,由一个IEntity的标识接口,EntityBase基类和N个Entity实体类组成,其中IEntity主要用来标识,在仓储操作时,用它来表明操作的实体范围和约束:EntityBase定义了几个公用的属性,为了避免代码的重复,特意将状态,插入时间和更新时间定义到了EntityBase里,而为何不将主键定义进来呢,主要考虑到主键的类型是为确实的,还有就是不同类型的主键可能需要实现不同的特性,如Mong…

Lind.DDD敏捷领域驱动框架~Lind.DDD各层介绍

回到目录 Lind.DDD项目主要面向敏捷,快速开发,领域驱动等,对于它的分层也是能合并的合并,比之前大叔的框架分层更粗糙一些,或者说更大胆一些,在开发人员使用上,可能会感觉更方便了,更益使用了,这就是大叔开发Lind.DDD框架的目的,让一切变得更简单... Lind.DDD层主要是公用方法,组件,规约等,如日志组件(Logger),消息组件(Messaging),IOC,AOP,缓存(Caching),异常,请求/响应,用户授权(Authorization),安全校验,领域模型(Domai…

Lind.DDD.ConfigConstants统一管理系统配置

回到目录 Lind.DDD.ConfigConstants属于新添加的组件,用来帮助我们安全的进行配置消息的管理,我们在开发项目时,有个感觉,你的config配置项会越来越多,越来越难以阅读,随着你引用的组件增多,添加更多的配置项也难以避免,而我自己的Lind.DDD框架也是如此,今天加个日志,明天加个消息,后天又加个缓存,相应的配置项越来越多,越来越零散,如何管理它成了一个大问题,这时ConfigConstants组件诞生了.它支持多种方式的持久化,有着自己的IoC容器,而项目其它IoC(如仓…