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

回到目录

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

拥有者接口

    /// <summary>
    /// 拥有者行为
    /// </summary>
    public interface IOwnerBehavor
    {
        /// <summary>
        /// 拥有者Id
        /// </summary>
        int OwnerId { get; set; }
    }

实体继承它

  /// <summary>
    /// 操作日志
    /// </summary>
    [TableAttribute("WebLogger")]
    public partial class WebLogger : Lind.DDD.Domain.Entity, Lind.DDD.Domain.IOwnerBehavor
    {
        /// <summary>
        /// 操作者ID
        /// </summary>
        [DisplayName("操作者ID")]
        public int UserId { get; set; }
        /// <summary>
        /// 操作者
        /// </summary>
        [DisplayName("操作者")]
        public string UserName { get; set; }
        /// <summary>
        /// 控制器名称
        /// </summary>
        [DisplayName("控制器")]
        public string ControllerName { get; set; }
        /// <summary>
        /// Action名称
        /// </summary>
        [DisplayName("Action")]
        public string ActionName { get; set; }
        /// <summary>
        /// 操作权限
        /// </summary>
        [DisplayName("操作权限")]
        public string Authority { get; set; }
        /// <summary>
        /// 当前请求的Get和Post参数JSON串
        /// </summary>
        [DisplayName("请求参数")]
        public string RequestParams { get; set; }
        /// <summary>
        /// 功能说明
        /// </summary>
        [DisplayName("功能说明")]
        public string Description { get; set; }

        #region IOwnerBehavor 成员

        public int OwnerId
        {
            get;
            set;
        }

        #endregion
    }

Lind.DDD.Manager集成它

功能主要有两个:修改单独表的拥有者和修改所有表的拥有者,如张三走了,由李四接管,这时我们通过拥有者接口就可以很方便的实现!

   /// <summary>
    /// 拥有者控制器
    /// </summary>
    public class OwnerController : Controller
    {
        /// <summary>
        /// 具有拥有者字段的数据表
        /// </summary>
        /// <returns></returns>
        public ActionResult Index()
        {
            return View(Lind.DDD.Utils.AssemblyHelper.GetTypeNamesByInterfaces(typeof(IOwnerBehavor)));
        }

        /// <summary>
        /// 更新指定表的拥有者字段
        /// </summary>
        /// <param name="id"></param>
        /// <returns></returns>
        public ActionResult Edit(string name)
        {
            ViewBag.Name = string.IsNullOrWhiteSpace(name) ? "全部表" : name;
            return View();
        }

        /// <summary>
        /// 更新表字段
        /// </summary>
        /// <param name="name"></param>
        /// <param name="val"></param>
        /// <param name="newVal"></param>
        void UpdateTable(string name, int oldVal, int newVal)
        {
            var type = AssemblyHelper.GetEntityTypeByName(name);
            Type reposType = typeof(ManagerEfRepository<>);
            var objType = reposType.MakeGenericType(type);
            object o = Activator.CreateInstance(objType);
            var entity = objType.InvokeMember("GetModel", BindingFlags.Default | BindingFlags.InvokeMethod, null, o, null);
            var atest = (IEnumerable)entity;

            var newList = (IList)Activator.CreateInstance(typeof(List<>).MakeGenericType(type));

            foreach (var item in atest)
            {
                if ((int)type.GetProperty("OwnerId").GetValue(item) == oldVal)
                {
                    var a = Convert.ChangeType(item, type);
                    type.GetProperty("OwnerId").SetValue(item, newVal);
                    newList.Add(item);
                }
            }

            objType.InvokeMember("BulkUpdate", BindingFlags.Default | BindingFlags.InvokeMethod, null, o, new object[] { newList, "OwnerId" });
        }
        [HttpPost]
        public ActionResult Edit(string name, FormCollection collection)
        {
            try
            {
                int oldVal;
                int.TryParse(collection["oldValue"], out oldVal);
                int val;
                int.TryParse(collection["newValue"], out val);

                if (string.IsNullOrWhiteSpace(name))//全部表
                {
                    foreach (var type in AssemblyHelper.GetTypeNamesByInterfaces(typeof(IOwnerBehavor)))
                    {
                        UpdateTable(type, oldVal, val);
                    }
                }
                else
                {
                    UpdateTable(name, oldVal, val);
                }

                return RedirectToAction("Index");
            }
            catch
            {
                throw;
            }
        }

    }

Lind.DDD.Manager运行结果

经过上面操作后,灵气表WebLogger里的OwnerId字段将由1变更为11,这就是面向接口的魅力,我们将某种特征抽象成接口,方便以后对这种特征进行统一的管理!

感谢各位的阅读!

回到目录

时间: 2024-10-24 01:42:06

Lind.DDD.Domain.IOwnerBehavor对实体的意义的相关文章

Lind.DDD.Domain.ISortBehavor~上移与下移

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

Lind.DDD.Domain领域模型介绍

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

Lind.DDD.ILogicDeleteBehavor~逻辑删除的实现

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

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

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

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

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

Lind.DDD.Messaging框架通讯组件介绍

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

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

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

Lind.DDD.Paging分页模块介绍

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

Lind.DDD.API核心技术分享

回到目录 关于Lind.DDD框架里API框架的技术点说明 讲解:张占岭 花名:仓储大叔 主要框架:Lind.DDD 目录 关于Lind.DDD.Authorization 关于授权的原理 关于ApiValidateModelConfig 关于Lind.DDD.CacheConfigFile 如何为你的API项目注入授权模块 关于服务端收取过滤器ApiValiadateFilter 如何在客户端生产加密授权串 关于请求类与响应类 客户端如何做分页 关于Lind.DDD.Authorization