Application of WEB API application architecture in WinForm Hybrid Framework (5)--how system-level dictionaries coexist with company-level dictionaries

In my series, I mainly use the Cloud Member management System I am developing as an example of the application of the Web API, because the cloud members of the data design is to support multiple merchant companies, and each company can also contain multiple stores, so some of the typical data needs to consider this difference. such as the document type, charge processing status, national, title , etc. these fixed content, we can put into the global dictionary inside, but for some such as member-related dictionary data, such as product units, product types and other content, if also all provisions as a global system dictionary, Then there is a lack of flexibility, and these data should be differentiated by their respective processes.

1. Dictionary data Model of cloud membership System

As the general Cloud Membership system is to allow users to register a company, and then the company level to open multiple shops, so the scope of the data need to consider a broader, their relationship is as follows.

The dictionary model we originally designed is shown below.

At the company data level, we need to consider the company-level data dictionary storage, but we can see further analysis, although the data dictionary data is corporate-level, but the type of data dictionary (such as document type, product type, etc.) these are fixed, that is, if we store the company-level dictionary data, Then you just need to store the corresponding dictionary items. So we can add one more table with Tb_dictdata data table to store it, and its data is designed as follows.

2, the company level of the dictionary data storage implementation

With the above design model, I believe most people can think of its specific implementation ideas.

First of all we need to take the system dictionary data as a reference, such as the default is to take the system dictionary project data, if the company level users modify or delete the dictionary data content, then the corresponding dictionary category dictionary items should be modified to prevail.

However, it is not possible for us to create a copy of the corresponding type of dictionary data for each company when creating a new company account, which is a bit cumbersome and cumbersome to create at the outset.

Establish a company dictionary data management Interface, which is the same as the Dictionary data management interface, but stored in another table, automatically based on the current user's company identity storage.

The data for the bulk add company dictionary is shown below.

In general, we use the company-level dictionary data, or the system's common-level dictionary data, according to the dictionary type to judge.

Therefore, at the company level according to the dictionary project type to obtain data, we at the bottom of the business interface to make a judgment, if the corresponding company's dictionary item has no data, then copy a past, if the company level has the corresponding data type, then obtain the company level of the dictionary project data can be.

The specific code logic is shown below.

        /// <summary>        ///gets all the dictionary list collections of that type based on the dictionary type name/// </summary>        /// <param name= "Dicttype" >Dictionary type name</param>        /// <param name= "Corpid" >Company ID</param>        /// <returns></returns>         PublicList<corpdictdatainfo> Findbydicttype (stringDicttypename,stringcorpid) {icorpdictdata dal= Basedal asIcorpdictdata; List<CorpDictDataInfo> list =dal.            Findbydicttype (Dicttypename, corpid); //If the company dictionary does not have data, get it from the system dictionary            if(list. Count = =0) {List<DictDataInfo> dict = bllfactory<dictdata>.                Instance.findbydicttype (Dicttypename); foreach(Dictdatainfo Infoinchdict) {list. ADD (NewCorpdictdatainfo (info, corpid)); }                //write to the company dictionary table to avoid getting it next time                foreach(Corpdictdatainfo Infoinchlist)                {Basedal.insert (info); }            }            returnlist; }

In the Controller interface of the Web API, as with other processing, the corresponding parameter processing can be added.

        /// <summary>        ///gets all the dictionary list collections of that type based on the dictionary type name/// </summary>        /// <param name= "Dicttype" >Dictionary type name</param>        /// <param name= "Corpid" >Company ID</param>        /// <returns></returns>[HttpGet] PublicList<corpdictdatainfo> Findbydicttype (stringDicttypename,stringCorpid,stringtoken) {                      //token Check, throw exception if not passedCheckresult Checkresult =Checktoken (token); returnBllfactory<corpdictdata>.        Instance.findbydicttype (Dicttypename, corpid); }

When the facade layer defines the corresponding interface of the dictionary, our code is as follows

        /// <summary>        ///gets all the dictionary list collections of that type based on the dictionary type name/// </summary>        /// <param name= "Dicttype" >Dictionary type name</param>        /// <param name= "Corpid" >Company ID</param>        /// <returns></returns>[OperationContract] List<CorpDictDataInfo> Findbydicttype (stringDicttypename,stringCORPID);

In the wrapper invocation interface based on the Web API, our call encapsulation class looks like this. The token and the relevant parameters of the Web API processing, in the base class module is encapsulated, reducing a lot of code splicing.

     /// </summary>        /// <param name= "Dicttype" >Dictionary type name</param>        /// <param name= "Corpid" >Company ID</param>        /// <returns></returns>         PublicList<corpdictdatainfo> Findbydicttype (stringDicttypename,stringcorpid) {            varAction ="Findbydicttype"; stringurl = Gettokenurl (action) +string. Format ("&dicttypename={0}&corpid={1}", Dicttypename, corpid); List<CorpDictDataInfo> result = jsonhelper<list<corpdictdatainfo>>.            Convertjson (URL); returnresult; }

Then our dictionary item drop-down list on the interface can be bound by extending the function.

        /// <summary>        /// Initializing the contents        of a dictionary list /// </summary>        Private void Initdictitem ()        {            // Initialize code            this. Txtproducttype.binddictitemsbycorp (" member Product type ", Loginuserinfo.companyid);        }

        /// <summary>        ///bind a drop-down list control to a specified list of data dictionaries [if the company dictionary record does not exist, use a system dictionary record, otherwise use company records]/// </summary>        /// <param name= "Combo" >Drop- down list control</param>        /// <param name= "Dicttypename" >data dictionary type name</param>         Public Static voidBinddictitemsbycorp ( ThisComboboxedit Combo,stringDicttypename,stringcorpid) {Binddictitemsbycorp (combo, Dicttypename, Corpid,NULL); }        /// <summary>        ///bind a drop-down list control to a specified list of data dictionaries [if the company dictionary record does not exist, use a system dictionary record, otherwise use company records]/// </summary>        /// <param name= "Combo" >Drop- down list control</param>        /// <param name= "Dicttypename" >data dictionary type name</param>        /// <param name= "defaultvalue" >Control Default Value</param>         Public Static voidBinddictitemsbycorp ( ThisComboboxedit Combo,stringDicttypename,stringCorpid,stringDefaultValue) {Dictionary<string,string> dict = callerfactory<icorpdictdataservice>.            Instance.getdictbydicttype (Dicttypename, corpid); List<CListItem> itemList =NewList<clistitem>(); foreach(stringKeyinchDict. Keys) {Itemlist.add (NewClistitem (Key, Dict[key]));        } binddictitems (Combo, itemList, DefaultValue); }

The above is a holistic approach, and in the system to solve the problem smoothly, I hope you can learn from.

Application of WEB API application architecture in WinForm Hybrid Framework (5)--how system-level dictionaries coexist with company-level dictionaries