Introduction and design of multi-form systems (1)

After three years of working in an enterprise, forms are the most commonly used. Various forms are ever-changing. Fortunately, they share the same thing: "form content + action name ". The most common business of Enterprise Office is dealing with forms. No matter what the leave application form or permission application form is, a series of workflow is required to complete it. Because of the frequent occurrence of such businesses, it is necessary to develop such systems in the context of rapid information development.

1. What is a multi-form system?

"Multi-form system", as its name implies, is a system composed of multiple forms in different forms. It is an extremely abstract concept. It is also a common management information system within an enterprise. The content and process of each form are different. It can be said that each form is a sub-system. In an enterprise, the requirements of different units are inconsistent, making it very difficult to design a general form system. Although it cannot be used in a general sense, and it cannot avoid adding new forms or modifying existing forms, it can still abstract some common things, such as the form action name. Therefore, we can abstract the unchanged parts to facilitate maintenance and add new requirements.

2. Requirements for multiple forms

1). Requirement Overview

A supervisor of an organization proposed to the software development department that our Organization had an application form and wanted to make it into a Web page. The process is:

Fill in the application form from the department engineers;

Then I will review it. If the review fails, I will return it to the applicant and apply again. If the review is passed, I will go to the handling unit supervisor for review;

If the supervisor of the processing unit fails to pass the review, the applicant will be returned to apply for a new application. If the application is approved, the application will be distributed to the handling personnel;

After the processing is completed, the handling unit supervisor is notified to close the case and the applicant.

This form flow is complete. Flowchart:

2). Functional Requirements

Based on the above requirements, we can design the following functions:

Form application: Application Form 1, Application Form 2 ,...... , Application Form n

Form query: Apply for form query and history form query

Form Review: Review, proxy Review

Proxy Settings: Default proxy settings and proxy Interval Settings

Form management: Assignment, work list, handling status

Report Management: Report 1, report 2 ,...... , Report n

System Management: Form settings, role management, process management, processing unit management, including form common part settings)

3). Form Action requirements

With the system function structure, different forms have different actions. To sum up, forms have the following actions:

Apply)

Modify)

Apply for Return again)

Cancel)

View)

Review Sign)

Assign)

Process)

Withdrawal Revoke)

Close)

There may be several steps for review. For example, the applicant's supervisor and the handling unit's supervisor may review the form several steps before the handling unit's supervisor review.

4). UI requirements

First, let's look at the UI abstract diagram:

From the UI Layer, the form system only has "Form Content", that is, the shadow part, which is changing. The content of each form is different, simple, and complex. A simple form, that is, an object can be understood as a database table, can meet the requirements. Complex forms require the combination of n entities to meet the requirements.

UI logic has different UI interfaces for different form actions, that is, the UI display logic should be considered. For example, a review page must be able to modify a column, for example, you can modify all content on the "desired completion time" or even some audit pages. In addition, the page for form processing is different from the page for form viewing. The processing page must upload a processing report, in addition, you can also determine what columns are displayed based on the role of the current publisher, what columns are not displayed, what functions are displayed, and what functions are not displayed. This is the connection between Operation permissions and UI.

There are still many requirements for the UI. I hope you can help me with this.

5). Business Needs

From the business perspective, the actions of each form are different, that is, the processing logic of each action is different, A simple operation is to insert data into a table or change the value of a field to a simple operation. A complicated operation is to operate n tables, including judgment, insertion, and modification, delete.

The business logic is complicated to write and the most difficult part of the system.

6). Changing requirements

For a multi-form system like this, the most annoying thing is that users constantly change their needs, which is inevitable in the development of enterprise management information systems. The following describes several common changes:

Add a column. This is only a matter of modifying the code. It is difficult to modify the code unless the form is automatically generated, but automatic generation has its limitations and cannot fully meet the requirements.

Added features. You also need to modify the code.

Add review process. The page and action processing logic need to be added. As long as the system is highly scalable and the interface design is used, adding a process is not very troublesome.

In the face of demand changes, we should have a way to cope with the changes, and try to reduce the number of places where we modify the code.

3. multi-form system design

1) technical framework

We adopt a familiar. NET platform to build a B/S multi-form system. The following is the main technical framework:

. NET Framework 3.5

ASP. NET WebForm

ASP. NET Ajax

JQuery

Due to frequent changes in enterprise application requirements, entity modification is inevitable. To facilitate modification and avoid changing multiple codes, we did not use the ORM technology, but directly write the code using SQL.

2) directory structure

First, let's look at the directory structure:

We can see that the project has three projects: Booking, Common, and Workflow.

The Common class library project stores public services of the system.

The Workflow class library project stores system Workflow services.

The Booking Project is a WebApplication with several main folders and pages.

3) Key System Designs

The key skill of the system is that all the services of each form subsystem use the pages shown in the figure above to complete the job, and there is no need to add corresponding functional pages for each form. Each page except some List pages) has a Panel control, which is the container for rendering the content of each form. The real content is implemented by dynamically loading the Editor and Viewer, each form has two user controls Editor and Viewer) and a Control class. Editor is the form Editor, Viewer is the form monitor, and Control is the form controller.

The inheritance relationships between controls and pages are as follows:

The FormControl FormApply and other form action methods in the figure are all virtual methods, and the real business logic is overwritten in the Editor and Viewer. In FormControl, The GetShowMode method applies, modifies, and reapplies to the Editor control by default. The Viewer control is loaded to other pages. If the Editor Control needs to be loaded on other pages, you can override the GetShowMode method in the Control class of each form.