Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of how to realize the front and back end of the distributed development of the medical registration system data dictionary module web. The content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this distributed development of the medical registration system data dictionary module web. Let's take a look.

The data dictionary can manage the classified data or fixed data commonly used in the system, such as provincial, municipal and regional three-level linkage data, ethnic data, industry data, education data and so on. Because our distributed medical registration system uses a lot of this kind of data, so we have to do a data management to facilitate the management of system data, and basically do data management in the general system.

The main function of the data dictionary is to make each item of data in the system more strict, which is helpful to reduce the bug caused by data problems.

1. Back-end interface 1. Database table design

The database table fields of the data dictionary and the attributes of the corresponding entity classes should correspond one to one, but pay attention to the following two points:

The addition of @ TableLogic indicates a logical deletion, and subsequent deletions will automatically become a modification operation. To achieve the ability to click to expand the child node on the page, use @ TableField (exist = false) to add the ha's'Children attribute.

two。 Write three-tier calls

According to the three-layer call relationship summarized in the following figure, we need to write the code for Controlller layer, Service layer and Mapper layer respectively.

Controller layer

After accessing the resource through url:/admin/cmn/dict/findChildData/ {id} to the control layer, the control layer invokes the findChildData (Long id) method of the service layer.

@ Api (tags = "data dictionary interface") @ RestController@RequestMapping ("/ admin/cmn/dict") @ CrossOriginpublic class DictController {@ Autowired private DictService dictService; @ ApiOperation (value = "query child data list based on id") @ GetMapping ("findChildData/ {id}") public Result findChildData (@ PathVariable Long id) {List list = dictService.findChildData (id); return Result.ok (list);}} Service layer

In the service layer, after querying the sub-data list according to id, calling the query method of the data layer to find the sub-data set, the collection is traversed, and the hasChildren attribute of each record is assigned in the traversal process. For more information on the business logic, please see the following code:

Service API inherits IService interface:

Public interface DictService extends IService {/ * query the child data list according to id * @ param id * @ return list * / List findChildData (Long id);}

The Service implementation class inherits the ServiceImpl class:

@ Servicepublic class DictServiceImpl extends ServiceImpl implements DictService {/ * query the child data list according to id * @ param id * @ return list * / @ Override public List findChildData (Long id) {QueryWrapper queryWrapper = new QueryWrapper (); queryWrapper.eq ("parent_id", id); List dictList = baseMapper.selectList (queryWrapper) For (Dict dict: dictList) {/ / get the id value of each record Long dictId = dict.getId (); / / call the hasChildren method to determine whether the child node boolean flag = this.hasChildren (dictId) is included; / / set the hasChildren attribute dict.setHasChildren (flag) for each record;} return dictList } / * determine whether there is a child node under id * @ param id * @ return true: with child node, false: no child node * / private boolean hasChildren (Long id) {QueryWrapper queryWrapper = new QueryWrapper (); queryWrapper.eq ("parent_id", id); Integer count = baseMapper.selectCount (queryWrapper); return count > 0;}} Mapper layer

The Mapper interface inherits the BaseMapper interface. Because the method called by the service layer is the method that comes with BaseMapper, we do not give a specific method in the data layer.

Public interface DictMapper extends BaseMapper {}

Since configuring classes and configuration files in the data dictionary module is not our main research content, it is no longer given here. Please refer to the github warehouse code for details. At this point, the back-end interface of the data dictionary module is complete:

Second, the front page 1. Add rout

Because the data dictionary in data management is a brand new page, we can set the route of the data dictionary to / cmn/list, and after routing to / cmn/list, we will jump to the / views/dict/list.js resource.

/ / data dictionary routing {path:'/ cmn', component: Layout, redirect:'/ cmn/list', name: 'data management', meta: {title: 'data management', icon: 'example'}, / / if only one level displays only child buttons, add alwaysShow=true to make the parent button also display alwaysShow:true Children: [{path: 'list', name:' data dictionary', component: () = > import ('@ / views/dict/list'), meta: {title: 'data dictionary', icon: 'table'}}]}, 2. Add a jump page

After routing, jump to the / views/dict/list.js page, and the logic snippet code of this page and the api API code it calls are given below:

3. Page table rendering

Table rendering We use elementUI to provide development documents: tree data and lazy load table components.

The modified code is as follows:

: data= "list"

The data found out.

: load= "getChildrens"

Load the getChildrens method.

: tree-props= "{children: 'children', hasChildren:' hasChildren'}"

The attribute value of the tree, which can be used to determine whether the value in hasChildren is true or false.

{{scope.row.name}} {{row.dictCode}} {{scope.row.value}} {{scope.row.createTime}} III. Standard Debug process

At present, the front and back end of the data dictionary module has been developed, but at this time, if the program is allowed, the page will not be loaded into the data passed from the back end. Because different access requests are accessed to different servers, we set port 8202 for the data dictionary module, while port 8201 from the previous hospital setting module is configured in the front-end config/dev.env.js.

We can add Nginx to solve the problem temporarily, and we will also add routing to replace Nginx later, but just to show the effect, we simply change the port in the front-end config/dev.env.js to the same port as the data dictionary module 8202. Nginx and the addition of unified routing will be covered in subsequent articles.

This is the end of the article on "how to implement the front and back end of web in the distributed development of medical registration system data dictionary module". Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "distributed development of medical registration system data dictionary module web front and back" knowledge. If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.