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

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

在进行列表排序时,有个“上移”和“下移”操作,这个一般在内存里完成,然后统一提交到数据库中,对于上移与下移的设计,大叔在LIND.DDD.DOMAIN里有一个ISortBehavor接口,主要是说,如果实体对象支持排序功能,可以实现这个接口,而在扩展库中,将有为本地结果集动态排序(上移和下移)的方法,这个设计类似于ABP项目里的软删除,当然在大叔LIND里也有对删除的逻辑操作. ISortBehavor内容 class Entity { public int ID{ get; set; } }…

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

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

回到目录 关于逻辑删除 对于逻辑删除之前的做法是在实体类中加个字段,一般是status,其中一种状态是删除,当然也有其它做法,如加个bool的字段IsDeleted,这些其实都过于武断,即它在基类里加上后,所以实体类都会有这种特性,而对于现实的数据表,可能不显示这种逻辑删除的特性,如关系表,日志表,可能删除就是物理上的直接delete,而这种删除字段加上去,我们的做也是在业务层手动调用update方法,或者在底层提供一个delete方法的重载,总之,感觉不是很爽! 看了ABP的软删除之后,对大叔…

回到目录 什么是LindAspects 之前写了关于Aspects的文章<Lind.DDD.Aspects通过Plugins实现方法的动态拦截~Lind里的AOP>,今天主要在设计思想上进行刨析一下,对缓存拦截器一直没有实现,所以文章了也一直没有发出来,让大家等这么久实在不好意思.LindAspects主要是面向切面编程AOP的一种实现,就像MVC框架里的Filter,Filter会自己注入到了每个Action执行的各个环节里,而我们可以直接实现自己的Filter即可,例如只要是继承Actio…

回到目录 Lind.DDD.Repositories.EF以下简称Repositories.EF,之所以把它从Lind.DDD中拿出来,完全出于可插拔的考虑,让大家都能休会到IoC的魅力,用到哪种方法持久化,就将那个DLL放到应用程序中,完全不需要把所有持久化方式耦合到一个项目里,这也是遵循了OCP的原则,对扩展是开放的,即你可以添加其它的持久化方式,在新的项目里:而不要在原有的项目中进行代码的修改． Repositories.EF做为数据持久化的一种方式,它直接继承了Lind.DDD.IRep…

回到目录 之前已经发生了 大叔之前介绍过关于redis的文章,有缓存,队列,分布式pub/sub,数据集缓存以及仓储redis的实现等等,而今天在Lind.DDD的持久化组件里,redis当然也有一席之地,作为当今最红的key/value存储机制,它在nosql的阵营中发挥着无可代替的作用! 下面是redis文章系列的目录,大家可以进行参考,看目录 Redis学习笔记~Redis在windows环境下的安装 Redis学习笔记~Redis在.net中的应用 Redis学习笔记~Redis提供的五…

回到目录 闲话多说 领域事件大叔感觉是最不好讲的一篇文章,所以拖欠了很久,但最终还是在2015年年前(阴历)把这个知识点讲一下,事件这个东西早在C#1.0时代就有了,那时学起来也是一个费劲,什么是委托,哪个是事件,搞的大家是糊里糊涂,进入C#2.0时代后,大叔也买了一本书,对于delegate和event这两个知识点看了至少有20几遍,感觉稍微有点明白了,明白了其中的真谛和用意. 委托:方法的规范,方法的模板,可以代表一类方法的集合 事件:委托的实例,事件在使用之前需要为它赋值,当然赋的就是一个…

回到目录 戏说当年 大叔原创的分布式数据集缓存在之前的企业级框架里介绍过,大家可以关注<我心中的核心组件(可插拔的AOP)~第二回 缓存拦截器>,而今天主要对Lind.DDD.Caching进行更全面的解决,设计思想和主要核心内容进行讲解.其实在很多缓存架构在业界有很多,向.net运行时里也有Cache,也可以实现简单的数据缓存的功能,向前几年页面的静态化比较流行,就出现了很多Http的“拦截器“,对当前HTTP响应的内容进行完整的页面缓存,缓存的文件大多数存储到磁盘里,访问的时间直接将磁盘上…

回到目录 大 家好,今天有时间来介绍一下Lind.DDD框架里的消息机制,消息发送这块一般的实现方法是将Email,SMS等集成到一个公用类库里,而本身 Email和SMS没什么关系,它们也不会有什么接口约定,即你想实现某种消息的多态发送,不需要程序代码,基本不可能实现,而在Lind.DDD里面, 大叔将它进行了抽象,消息有自己的统一接口,而对于email和sms只是一种实现而以,这样,就可以发挥面向对象的特性,在sms,email甚至是 rtx上进行消息的灵活切换了,说到这样,您心动了吧! L…

回到目录 分页组件网上有很多,MVC.Pager,JSPager等,通过实现方式大体分为前端分页和后端分页,前端分页是前台对list内存本地集合进行分页,缺点就是在大数据情况下,内存占用过高:后端分页就是UI把要返回的页号告诉后台,由后台组织数据并返回,这种方法就是我们经常看到的了:而根据后台集合种类又可以分类List和IQueryable,前者是本地集合,在返回数据时,直接把第几页共几条的集合返回:IQueryable是预查询集合,它是Linq的产物,在很多地里它不通用,除非你的ORM框架支持…

回到目录 之前已经发生了 大叔之前讲过被仓储化了的Mongodb,而在大叔开发了Lind.DDD之后,决定把这个东西再搬到本框架的仓储层来,这也是大势所趋的,毕竟mongodb是最像关系数据库的NoSql,它的使用场景是其它nosql所不能及的,这点是毋庸置疑的! 下面是大叔总结的Mongodb文章目录,选自<大叔Mongodb系列> MongoDB学习笔记~环境搭建 (2015-03-30 10:34) MongoDB学习笔记~MongoDBRepository仓储的实现 (2015-04-…

回到目录 Lind.DDD.Authorization是Lind.DDD框架的组成部分,之所以把它封装到框架里,原因就是它的通用性,几乎在任何一个系统中,都少不了用户授权功能,用户授权对于任何一个系统来说都是必要的,像管理型的页面都需要用户先去登陆,然后拿到凭证,才可以进行访问,这在MVC和WebApi体系结构里是很容易实现的,像过滤器里的AuthorizeAttribute和ActionFilterAttribute都可以实现用户授权的功能. AuthorizeAttribute和Action…

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

回到目录 Lind.DDD框架里提出了对数据集的控制,某些权限的用户为某些表添加某些数据集的权限,具体实现是在一张表中存储用户ID,表名,检索字段,检索值和检索操作符,然后用户登陆后,通过自己权限来构建对应表的查询语句,即动态构建表达式树,这种操作一些被写在业务层上,我们可以在业务层需要进行数据集权限控制的地方,添加这种策略,下面具体分析说明一下． 看一下数据集权限表结果 public class User_DataSet_Policies { /// <summary> /// 用户ID /…

回到目录 关于Lind.DDD.Api的使用与客户端的调用 作者:张占岭 花名:仓储大叔 框架:Lind.DDD,Lind.DDD.Api 目录 Api里注册全局校验特性 1 Api中设置全局的Cors跨域资源访问 2 Api直接返回Json,而不是Xml 2 Api中Controller的Get,Post,Put和Delete 3 Api中Controller几大方法重载要注意的 3 客户端如何调用Api 4 对ResponseMessage的结果按需返回 5 对ResponseMessage…

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

回到目录 对于Lind.DDD这个敏捷框架来说,插件也是其中的一个亮点,所有被认为是插件(Plugins)的模块都会继承自IPlugins这个标示接口,它在程序启动时会找到所有插件,并通过autofac注册到运行时中,然后在使用时通过PluginManager对象进行获取,即所有模块只注册一次,在使用时只是从容器中取出实例的过程,这也保证的程序的性能! Lind.DDD.Plugins设计图 一个接口,多个实现,根据具体业务,生产不同的实例,生产的过程前制到程序启动时,后期的使用直接从容器中获取…

回到目录 一般sso的说明 在Lind.DDD框架里,有对单点登陆的集成,原理就是各个网站去sso网站统一登陆授权,之后在sso网站将登陆的token进行存储,存储方式随你(cache,redis,mongodb,file),之后业务平台在访问资源时,如果这些资源需要用户登陆才能访问,就会去sso网站取token,再根据token去凭证,然后将cookies(由sso域名+token值组成)存储到自己浏览器的cookies里,同时在自己的业务平台也存储的登陆状态,当退出后,将sso上存储的信息清…

回到目录 Redis本身支持事务,这就是SQL数据库有Transaction一样,而Redis的驱动也支持事务,这在ServiceStack.Redis就有所体现,它也是目前最受业界认可的Redis驱动,而它将Redis的事务机制(MULTI,Exec,Watch等)封装成了比较友好的实现方式,如下面的代码 using (IRedisClient RClient = prcm.GetClient()) { using (IRedisTransaction IRT = RClient.Creat…

回到目录 两雄争霸 使用StackExchange.Redis的原因是因为它开源,免费,而对于商业化的ServiceStack.Redis,它将一步步被前者取代,开源将是一种趋势,商业化也值得被我们尊重,毕竟人家研究代码也不容易,做商品也很正常,当然这不是我们今天的重点,今天主要说一下对StackExchange.Redis的封装,它与ServicesStack.redis最大的不同就是,它没有线程池的概念,这对于初学者绝对是个坑,大家使用时一定要注册,StackExchange.redis的对…

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

回到目录 工作单元UoW我们几乎在任务一个像样的框架里都可以找到它的足迹,是的,对于大型系统来说,他是很重要的,保持数据一致性,维持事务状态这都是它要为系统实现的功能,而在不同的框架里,实现UoW的机制也是不同的,在Lind.DDD中,采用了一种共同注册,统一提交的方式来实现UoW! UoW结构图…

回到目录 IoC是解耦的灵魂,很难想像一个框架中没有IoC会变成什么样子,Lind.DDD里的IoC是通过Unity实现的,由依赖注入(unity)和方法拦截组成(Interception),依赖注入可以通过事前定义好的实现方式去动态建立某个接口的实例,例如,在仓储接口IRepository里,你可以在配置文件中定义它由EF实现,也可以让它由Mongodb实现,而表现出来的结果就是数据的持久化方式的不同. 模块的结构…

回到目录 让大叔兴奋的自动化注册 对于领域事件之前说过,在程序启动时订阅(注册)一些事件处理程序,然后在程序的具体位置去发布(触发)它,这是传统的pub/sub模式的体现,当然也没有什么问题,为了让它支持分布式的场景,我们引用了redis这种存储介质,这一切都早已集成到了Lind.DDD架构中,对些没什么好说的,而今天的重点在于＂事件的自动过注册＂的理念,这个概念真实在ABP架构中出现了,大叔觉得很不错,所以也集成到了自己的架构中,为些也兴奋了一段时间,其中有解决问题的 Redis只是一种分布式…

回到目录 对于一个后台管理系统来说,你的权限设计与安全是重中之重,当你为一个权限分配一些菜单后,当这个权限的用户没有菜单权限时,这个菜单的URL是不可以被用户访问的,而在之前的设计中,没有考虑到这点,所以本次Lind.DDD.Manager的升级中,需要把这块完善一下,将会在8月的Lind.DDD中奉献给大家,敬请期待! 思路 用户访问 ==> mvc根据url找到controller/action ==> 判断这个URL是否为库中定义的URL(排除非正常URL,PartialView产生的U…

回到目录 关于依赖倒置(DIP) 高层模块不依赖于低层模块的实现,而低层模块依赖于高层模块定义的接口,通俗的讲,就是高层模块定义接口,低层模块负责实现,这在我们实际开发中经常被用到,层与层之间引用,经常被添加一个接口层去隔离,在接口层定义相关业务规范,而底层去实现它,高层只引用这个接口,当高级需要其它扩展,直接添加新的接口,由新的底层模块去实现即可,底层其它代码不需要修改,这也完全复合开闭原则(OCP)． 关于控制反转(IOC) 控制反转是一种设计模式,像单例,工厂,适合器都属于设计模式的一种,…

回到目录 关于Lind.DDD.Manager的培训与学习 讲解:张占岭 花名:仓储大叔 主要框架:Lind.DDD,Lind.DDD.Manager 关于Lind.DDD.Manager 由于数据模型,数据库初始化(Code.First自动升级数据库或者进行数据库版本的迁移)控制器,View视图,css,js等元素组件的一套标准的后台管理系统框架,可以直接应用到任何一个系统上,可以它将发布到Nuget上,以后安装和更新更加方便.…