Web API应用架构在Winform混合框架中的应用(5)--系统级别字典和公司级别字典并存的处理方式

在我这个系列中,我主要以我正在开发的云会员管理系统为例进行介绍Web API的应用,由于云会员的数据设计是支持多个商家公司,而每个公司又可以包含多个店铺的,因此一些字典型的数据需要考虑这方面的不同。如对于证件类型,收费处理状态,民族,职称等这些固定化的内容,我们可以放到全局字典里面,但是对于一些如会员相关的字典数据,如产品单位、产品类型等内容,如果也全部规定为全局的系统字典,那么就缺乏灵活性,这些数据应该可以由各自进行差异化处理。

1、云会员系统的字典数据模型

我们先来了解下基于Web API接口的云会员管理系统的总体界面效果。

由于一般的云会员系统,都是允许用户注册一个公司,然后公司层面开设多个商铺的,如系统的登陆界面如下所示。

因此数据的范围需要考虑的更广,他们的关系如下所示。

而我们原先设计的字典模型如下所示。

而在公司数据这个层次上,我们需要考虑公司层级的数据字典存储,但是我们进一步分析可以看到,虽然数据字典数据是公司层级的,但是数据字典的类型(如证件类型、产品类型等)这些是固定不变的,也就是我们如果存储公司层级的字典数据,那么也只是需要存储对应的字典项目即可。因此我们可以增加多一个和TB_DictData的数据表类似的表进行存储即可,它的数据设计如下所示。

为了方便在系统里面使用同一的字典项目内容,我们创建一了一个统一的字典项目管理模块,也就是系统字典管理界面,如下所示。

2、公司层级的字典数据存储实现

有了上面的设计模型,相信大多数人员都可以想到它的具体实现思路了。

首先我们需要以系统字典数据为参考,如默认就是取系统的字典项目数据,如果公司级别的用户修改或者删除了字典数据内容,那么对应的字典类别的字典项目就应该以修改的为准了。

但是我们不可能为新建公司账户的时候,都为每个公司自动创建一份对应类型的字典数据,那样稍显麻烦,而且一开始就创建也比较麻烦。

先建立一个公司字典的数据管理界面,它和字典数据管理界面一样,不过是存储在另外一个表里面,自动根据当前用户的公司标识进行存储的。

批量添加公司字典的数据如下所示。

一般我们在使用公司层级的字典数据或者系统公共层级的字典数据的时候,都是根据字典类型进行判断的。

因此在公司层级根据字典项目类型获取数据的时候,我们在业务接口底层做了判断,判断如果对应公司的字典项没有数据,则复制一份过去,如果公司层次有对应的数据类型,那么就获取公司层级的字典项目数据即可。

具体的代码逻辑如下所示。

        /// <summary>
        /// 根据字典类型名称获取所有该类型的字典列表集合
        /// </summary>
        /// <param name="dictType">字典类型名称</param>
        /// <param name="corpId">公司ID</param>
        /// <returns></returns>
        public List<CorpDictDataInfo> FindByDictType(string dictTypeName, string corpId)
        {
            ICorpDictData dal = baseDal as ICorpDictData;
            List<CorpDictDataInfo> list = dal.FindByDictType(dictTypeName, corpId);

            //如果公司字典没有数据,则从系统字典获取
            if (list.Count == 0)
            {
                List<DictDataInfo> dict = BLLFactory<DictData>.Instance.FindByDictType(dictTypeName);
                foreach (DictDataInfo info in dict)
                {
                    list.Add(new CorpDictDataInfo(info, corpId));
                }

                //写入公司字典表,避免下次再去获取
                foreach (CorpDictDataInfo info in list)
                {
                    baseDal.Insert(info);
                }
            }
            return list;
        }

在Web API的控制器接口,还是和其他的处理一样,增加对应的参数处理即可。

        /// <summary>
        /// 根据字典类型名称获取所有该类型的字典列表集合
        /// </summary>
        /// <param name="dictType">字典类型名称</param>
        /// <param name="corpId">公司ID</param>
        /// <returns></returns>
        [HttpGet]
        public List<CorpDictDataInfo> FindByDictType(string dictTypeName, string corpId, string token)
        {
            //令牌检查,不通过则抛出异常
            CheckResult checkResult = CheckToken(token);

            return BLLFactory<CorpDictData>.Instance.FindByDictType(dictTypeName, corpId);
        }

在Facade层定义字典的对应接口的时候,我们的代码如下所示

        /// <summary>
        /// 根据字典类型名称获取所有该类型的字典列表集合
        /// </summary>
        /// <param name="dictType">字典类型名称</param>
        /// <param name="corpId">公司ID</param>
        /// <returns></returns>
        [OperationContract]
        List<CorpDictDataInfo> FindByDictType(string dictTypeName, string corpId);

在基于Web API的封装调用接口,我们的调用封装类如下所示。其中token以及Web API的相关参数处理,在基类模块进行了封装,减少了很多代码的拼接。

     /// </summary>
        /// <param name="dictType">字典类型名称</param>
        /// <param name="corpId">公司ID</param>
        /// <returns></returns>
        public List<CorpDictDataInfo> FindByDictType(string dictTypeName, string corpId)
        {
            var action = "FindByDictType";
            string url = GetTokenUrl(action) + string.Format("&dictTypeName={0}&corpId={1}", dictTypeName, corpId);

            List<CorpDictDataInfo> result = JsonHelper<List<CorpDictDataInfo>>.ConvertJson(url);
            return result;
        }

然后我们在界面上的字典项目下拉列表,则可以通过扩展函数的方式进行绑定。

        /// <summary>
        /// 初始化字典列表内容
        /// </summary>
        private void InitDictItem()
        {
            //初始化代码
            this.txtProductType.BindDictItemsByCorp("会员产品类型", LoginUserInfo.CompanyId);
        }
        /// <summary>
        /// 绑定下拉列表控件为指定的数据字典列表[如果公司字典记录不存在,则使用系统字典记录,否则使用公司记录]
        /// </summary>
        /// <param name="combo">下拉列表控件</param>
        /// <param name="dictTypeName">数据字典类型名称</param>
        public static void BindDictItemsByCorp(this ComboBoxEdit combo, string dictTypeName, string corpId)
        {
            BindDictItemsByCorp(combo, dictTypeName, corpId, null);
        }

        /// <summary>
        /// 绑定下拉列表控件为指定的数据字典列表[如果公司字典记录不存在,则使用系统字典记录,否则使用公司记录]
        /// </summary>
        /// <param name="combo">下拉列表控件</param>
        /// <param name="dictTypeName">数据字典类型名称</param>
        /// <param name="defaultValue">控件默认值</param>
        public static void BindDictItemsByCorp(this ComboBoxEdit combo, string dictTypeName, string corpId, string defaultValue)
        {
            Dictionary<string, string> dict = CallerFactory<ICorpDictDataService>.Instance.GetDictByDictType(dictTypeName, corpId);
            List<CListItem> itemList = new List<CListItem>();
            foreach (string key in dict.Keys)
            {
                itemList.Add(new CListItem(key, dict[key]));
            }

            BindDictItems(combo, itemList, defaultValue);
        }

以上就是一个整体性的思路,并在系统中能够顺利解决问题的做法,希望大家可以借鉴。

系列文章如下所示:

Web API应用架构在Winform混合框架中的应用(1)

Web API应用架构在Winform混合框架中的应用(2)--自定义异常结果的处理

Web API接口设计经验总结 

Web API应用架构在Winform混合框架中的应用(3)--Winfrom界面调用WebAPI的过程分解

Web API应用架构在Winform混合框架中的应用(4)--利用代码生成工具快速开发整套应用

Web API应用架构在Winform混合框架中的应用(5)--系统级别字典和公司级别字典并存的处理方式

本文转自博客园伍华聪的博客,原文链接:Web API应用架构在Winform混合框架中的应用(5)--系统级别字典和公司级别字典并存的处理方式,如需转载请自行联系原博主。

时间: 2024-10-22 11:38:41

Web API应用架构在Winform混合框架中的应用(5)--系统级别字典和公司级别字典并存的处理方式的相关文章

Web API应用架构在Winform混合框架中的应用(1)

在<Web API应用架构设计分析(1)>和<Web API应用架构设计分析(2)>中对WebAPI的架构进行了一定的剖析,在当今移动优先的口号下,传统平台都纷纷开发了属于自己的Web API平台,方便各种终端系统的接入,很多企业的需求都是以Web API优先的理念来设计整个企业应用体系的.Web API作为整个纽带的核心,在整个核心层需要考虑到统一性.稳定性.以及安全性等方面因素.本文主要介绍,Web API应用架构,在Winform整合中的角色,以及如何实现在Winform混合

Web API应用架构在Winform混合框架中的应用(2)--自定义异常结果的处理

在上篇随笔<Web API应用架构在Winform混合框架中的应用(1)>中我介绍了关于如何在Winfrom里面整合WebAPI,作为一个新型数据源的接入方式,从而形成了三种不同的数据提供来源,前文在介绍整体性框架方面,着笔较多,注重整合的统一性,但是在Web API方面还不算很具体,本系列将继续这个主题,介绍Web API开发中常见到的一些问题,对其中各个技术要点进行总结,本文主要介绍Web API自定义异常结果的处理. 1.常规的异常处理 统一的异常处理,把正确的信息返回给调用者很重要,可

Web API应用架构概括分析和设计实例教程

1.Web API的核心层设计 在目前发达的应用场景下,我们往往需要接入Winform客户端.APP程序.网站程序.以及目前热火朝天的微信应用等,这些数据应该可以由同一个服务提供,这个就是我们所需要构建的Web API平台,基于上述的需求,很多企业的需求都是以Web API优先的理念来设计整个企业应用体系的.Web API作为整个纽带的核心,在整个核心层需要考虑到统一性.稳定性.以及安全性等方面因素. 从上图我们可以看到,整个外围的应用场景围绕着Web API核心层构建,如果我们把它换一种方式表

Web API应用架构设计分析(1)

Web API 是一种应用接口框架,它能够构建HTTP服务以支撑更广泛的客户端(包括浏览器,手机和平板电脑等移动设备)的框架, ASP.NET Web API 是一种用于在 .NET Framework 上构建 RESTful 应用程序的理想平台.本文主要以ASP.NET Web API 的框架实现来介绍整个Web API应用架构设计,但不局限于.NET的技术. 1.Web API的核心层设计 在目前发达的应用场景下,我们往往需要接入Winform客户端.APP程序.网站程序.以及目前热火朝天的

混合框架中Oracle数据库的还原处理操作

在较早期的随笔<Oracle如何实现创建数据库.备份数据库及数据导出导入的一条龙操作>粗略介绍了Oracle数据库的备份还原操作,本文想从开发框架的基础上介绍Oracle数据库的脚本或者还原操作. 我们在Winform开发框架.混合式开发框架.Web开发框架等各种开发框架,底层都是支持多种数据库的,如MS SQLServer.Oracle.MySQL.SQLite.PostgreSQL等等,如下图所示. 其中SQLServer支持最为常用,而且也是最为方便备份还原的操作,而Oracle数据库这

可否把arcgis api for javascript整合到primefaces框架中?

问题描述 primefaces框架是基于jsf的,很漂亮!!!如果可以,可否给个实例代码?如果不可以,那为什么呢? 解决方案 解决方案二: 自己搞定了.

Winform混合式开发框架访问Web API接口的处理

在我的混合式开发框架里面,集成了WebAPI的访问,这种访问方式不仅可以实现简便的数据交换,而且可以在多种平台上进行接入,如Winform程序.Web网站.移动端APP等多种接入方式,Web API的处理方式和微信提供的接口处理规则类似,也是通过向服务器获得访问令牌(AccessToken),然后传递给每个Web API接口,实现数据的交换处理.本篇随笔主要介绍混合框架中Winform对Web API访问的处理. 1.Web API接入方式介绍 <混合式开发框架>混合了Web API接口访问.

Web API项目中使用Area对业务进行分类管理

在之前开发的很多Web API项目中,为了方便以及快速开发,往往把整个Web API的控制器放在基目录的Controllers目录中,但随着业务越来越复杂,这样Controllers目录中的文件就增加很快,难以管理,而且如果有不同业务模块有重复的控制器名的话,还需要尽量避免.引入Area的作用就是把控制器按照不同的业务模块进行区分,方便管理,而且控制器名称可以重名. 1.Web API项目引入Area进行分类 Area在项目中可以称之为区域,每个Area代表应用程序的不同功能模块,Area 使每

Web API接口设计经验总结

在Web API接口的开发过程中,我们可能会碰到各种各样的问题,我在前面两篇随笔<Web API应用架构在Winform混合框架中的应用(1)>.<Web API应用架构在Winform混合框架中的应用(2)--自定义异常结果的处理>也进行了总的介绍,在经过我的大量模块实践并成功运行后,总结了这篇随笔,希望对大家有所帮助. 1.在接口定义中确定MVC的GET或者POST方式 由于我们整个Web API平台是基于MVC的基础上进行的API开发,因此整个Web API的接口,在定义的时