DBFORM design source and main ideas
?
DBForm's design idea comes from the requirements of my recent student information management system, and the summary information required by the information system is more than the fuzzy lookup (loan, scholarship, hard work student, examination, personal situation, etc.) . Examples of the inquiry of loans, including personal basic situations such as student number, name, class, grade, and college, home income status, regional, learning grade, etc., etc., and loan categories, loan time, loan The specific information of the amount and other loans, the amount of data is large, and the SQL statement used to query is very troublesome. Moreover, more modules to be completed, the query information of each module is substantially the same, if each module is written separately , Workload is really large
?
After carefully analyzing the functionality of each module, we found the interface between modules, mainly moderately similar, different, mainly for querying fields and form control names, etc., so we started the refining work of the entire code. , Proposed basic DBFORM concept
: Depending on the control group in the traversal form, extract the database field to be queried and the data input by the user.
In the WinForm form, there is a very good TAG property that can be very convenient to save the data we need.
In the WebForm form, unfortunately, there is no tag attribute, we will inherit the class, add TAG properties to meet the addition requirements of our DBFORM Squadron Database sub-end
?
The query includes not only the field name, but also the specific query operation (such as TAG attributes in the TextBox control we define as database field _ operator, example: studentId_like, intuitive, very image, and LIKE operator can run during operation Dynamic change becomes "=" and other operators, implement exact matching)
?
In the architecture of the entire DBForm, you can have enough support, the current requirement is to support WinForm and WebForm at the same time, we use the method of generating the form of the form data and the generation of the database-related SQL statement. May increase the elasticity of the entire system, the middle, and the FormInfoentity class is used to package the form data package, transfer
The FormInfoEntity class mainly includes FormInfolist, JoinInfoList, where the FormInfolist is maintained mainly in the extracted database field and the corresponding user input information, the type of field (value or string), and the operation symbol, etc. JoinInfolist is mainly the connection information of the table to be queried.
?
In the writing of the entire DBFORM, I found that the architecture of the entire system is not only used with the query, but also has a lot of use when repairing, adding, delete, as long as the relevant form is extracted, the SQL statement The generation is a very easy job, so I extend the function of modifying the database, the entire job is to add relevant SQL generation classes and form information parsing classes (for modifying form information and for use The form information description of the query is different)
?
The entire DBFORM architecture is more scalable, and it is possible to meet the requirements of future data sources, such as the XML file in InfoPath, related queries from WebService, etc.
