Design of Multi-Form System Framework Based on ASP. NET

　　Question:I wrote two short articles about multi-form system analysis. I just thought it was not reasonable to separate the design of the multi-form system framework. So I merged the first two short documents into this article, A complete description of the multi-form system development framework. In the previous two short comments, the brothers in the garden recommended some good tools. Thank you first.

　　Abstract: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). Requirements 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 common part settings of forms)

(3). Form Action requirements

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

Apply)

Modify)

Return)

Cancel (Cancel)

View)

Sign)

Assign (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) changing. The content of each form is different, simple, and complex. A simple form, that is, an entity (which 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.This requires the addition of page and action processing logic. As long as the system is highly scalable (with an interface design), 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.

• Three pages in total:
• Previous Page
• 1
• 2
• 3
• Next Page