Architecture Design of A Graphical Data Maintenance Tool

 Architecture Design of A Graphical Data Maintenance Tool

 

1. Background

Recently, Alibaba Cloud is responsible for a GIS vectoring project involving the associated storage and management of graphic data and GIS business data. To make up for the limitations of the image vectorization software in the management of affiliated attributes, two sets of database systems are used for graph-number associated storage: The graphic vectorization software stores graphic data and the file database stores business data. The graphic data maintenance tool is a data inspection and correction tool outside the core supporting system in the vectorized Implementation Project. It mainly establishes and maintains the graph-number correspondence relationship, basic check and correction of business data legitimacy.

2. Requirements Overview

In terms of information management, the entire project involves the storage of a large number of isolated images, including: image File name, business path, corresponding project, graphic processor, business processing flow, processing status, etc. Business Data includes: project information, GIS Point Facility business data, GIS Line facility business data, GIS layer information, GIS various points, Line facility geometric rules, topological relationships, business rules, and so on. The graphic data maintenance tool needs to operate the business database corresponding to each raster map, read and correct the business attributes corresponding to each isolated graphic project, and operate the data management system of the entire project, synchronize the information of the central database with the information of each isolated project, and batch correct the project file data involving the rule according to the unified business rules.

The Data Management and Application of graphic data maintenance tools are as follows:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1646455A4-0.jpg "alt =" "style =" border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; "/>

3. Architecture Design

Graphical Data maintenance tools are designed in vertical layers: persistence layer, Business Entity layer, business rule layer, and interface interaction layer.

The data access layer encapsulates operations on various databases, reports, and log files. Including: MySQL database interface, SQLite database interface, Excel File Operation encapsulation, txt Log File encapsulation, XML file access encapsulation, etc.

The Business Entity layer defines and encapsulates data structures, classes, constants, and so on for projects, project personnel, layers, various point facilities, various line facilities, and core rule entities.

Business Rule layer, set Basic geometric rules, GIS topology, business data check rules, business data correction rules, business property border check rules, business data error check rules, and business data error correction rules for points and lines. rules.

User Interface Layer: displays various file, database, business data, report processing, and other operation interfaces.

The overall architecture of the Graphic Data Maintenance Tool is shown as follows:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1646454R7-1.jpg "alt =" "style =" border-top-style: none; border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; "/>

 

4. Summary

First, database operations are completely encapsulated.

Graphical Data maintenance tools mainly deal with databases. Years of design and coding develop a habit of fully encapsulating database operations in specific objects, SHIELD database differences and shield all details of the database (including SQL statements, table names, field names, views, stored procedures, SQL functions, etc ). Do not write SQL statements and reference the names of tables and fields as you like in the code. Restrict database changes to specific SQL definition files and separate classes.

Second, data is completely isolated.

Between the database object and the upper-layer data requirement object, try to avoid using the database's own dataset to interact with the data, and specifically design the data structure, no method entity class, and other methods to interact with the data. Directly disconnects upper-layer businesses from databases; prevents upper-layer data operation errors from leading to frequent underlying database exceptions or unknown exceptions of underlying data sets from leading to disordered upper-layer business processing logic; it also facilitates system testing, problem debugging, locating, and BUG fixes.

Third, business entity and business process separation design.

Object-oriented allows you to add methods to an object, often tempting Experienced designers and developers to add more and more methods to an object without thinking, even without restraint, you can directly create a peer object to complete its own functions. This makes the functions of some objects very bloated and looks very powerful. In this system, after a rough preliminary design, we constantly rebuild the development and implementation process to gradually remove and move the responsibilities of the original business entity objects, add business rule objects to form an independent business rule layer. Specialized collection of complex business rules that require interaction across multiple business entities: data extraction, legality check, association analysis, data correction, and other functions. Facts have proved that such design and code Refactoring can flexibly combine multiple entity objects to quickly implement new business rules; the entity object business method is relatively stable and uniform, but the degree of reuse is very high, that is, the fan-in coefficient of the module is large); the business rules and Entity objects, their respective data and method boundary logic are clear, the negative effects of code errors are not easy to spread; program bugs are easy to locate and modify.

Fourth, the interface should be inherited as much as possible.

Because it is not a B/S system, you prefer to inherit directly. With the gradual improvement of functions, any system will always find the commonalities between various interactive interfaces, such as the same overall interface layout, main interactive component buttons, input boxes, selection boxes, and tables) similar, the same as the object to be processed, the display of information, and so on. Through abstract classes like, identical, identical, and identical, a reasonable interface object hierarchy is established, compiling common functional methods, similar abstract methods, and similar virtual functions on the base class can greatly reduce the interface design and development time, and improve the consistency of interactive data verification, avoid unnecessary code duplication and redundancy. Reducing the amount of code is equivalent to reducing the incidence of bugs, or modifying a small number of bugs can correct a large number of errors.