X-Admin&ABP框架开发-数据字典

  在业务型的系统开发中,我们需要维护各种个样的类型,比如客户类型、客户行业、商品类型等等,这些类型往往信息量不多,并且相似度极高,如果采用一类型一表去设计,将会造成极大的工作量,通过将这部分类型的信息进行抽象,利用字段去存储类型区分,共用表结构,来达到兼容各种类型的功能,也就是设计一个数据字典,而对于一个具体类型来讲,是有多个选项的,比如性别,有男女,行业有工农商等,对于这部分选项,可抽象为某个类型下的字典项,即数据字典项。

 

一、数据字典设计思路

  1、从客户类型、商品类型、行业类型来抽象考虑,首先三者都存在一个类型描述,即客户、商品、行业,同时,三者是本质是不同的,并且,随着业务上的需求越来越多,更多的xx类型将会加入,因此,单从类型考虑出发,就存在三个点了,如类型名称、类型独立、数量扩展,因此在考虑表结构设计时,就可以先考虑到这三点了,同时还有一个关键的信息,便是,在系统设计过程中,这些类型其实便已经确定完毕了,而不是说,在开发完毕,再去系统中增加类型。

   

X-Admin&ABP框架开发-数据字典

   2、从具体的某个类型出发考虑,比如以商品类型为例,存在日用品、电子产品、化妆品等,同样是存在几个关键信息,比如类型项名称、类型项独立、类型项数量扩展,类型项的归属,而这部分信息,往往是由客户去维护的,属于系统开发完毕后期的信息维护,在此,不考虑类型项的先后顺序问题,如有需要可以扩展。

   

X-Admin&ABP框架开发-数据字典

  按照这些信息点,可以对数据字典设计一些必要的字段,如类型名称即TypeName、 类型独立便是类型间相互独立,但是这里也存在一个类型间的上下父子问题,暂不加入进来,该父子问题使用场景较少,但又存在,如果按照“二八原则”的话,我还是喜欢把“八”的部分完成。对于数据字典项而言,按照给定的必要信息,设计成如下结构,其中的业务代码,是需要唯一的,比如对于性别来将,业务代码便是1或0,来代表男女,这部分可由客户的系统管理员进行维护。

  

X-Admin&ABP框架开发-数据字典

 

二、完成数据字典设计

   在明确了这些基础信息后,开始在项目中完成设计过程,首先得明确数据字典本身的归属,数据字典是为整个业务而服务的,因此我把它划分到核心层这一级别中,首先在领域层设置Core层文件夹,用来存放为整个业务提供基础设施的功能模块。

   

X-Admin&ABP框架开发-数据字典

  1、在Core层中加入数据字典模块,结构设计如:

  

X-Admin&ABP框架开发-数据字典

  开始创建数据字典类,并添加设计的字段,以保证够用为前提,或许更多场景下会出现诸如父子字典情形,或是对字典内容的描述等,暂不考虑。

/// <summary> /// 核心_数据字典 /// </summary> [Table("Core_DataDictionary")] public class DataDictionary : Entity<long> { public const int MaxNameLength = 30; /// <summary> /// 字典类型 /// </summary> [StringLength(MaxNameLength)] public string TypeName { get; set; } /// <summary> /// 关联数据字典项 /// </summary> public virtual ICollection<DataDictionaryItem> DataDictionaryItem { get; set; } }

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wppfsp.html