RFID conference sign-in system summary (III)-module Overview (I)

 

This article describes the various modules of the system as a whole to understand the process of forming the system surface.

First, it is clear thatCSSystem, the system has offline requirements, and more importantly, the client needs to access hardware devices, and the display and refresh of the client must meet the quasi real-time requirements.BSThe architecture is hard to implement.

Determine the development environment first. Vs. NET 2003 , Sqlserver 2000 . At that time Vs2005 And Sqlserver 2005 Although it has been used more and more, it does have many attractive features, but for non- BS In terms of development, in my opinion, the advantages are not obvious. And relatively speaking . NET Framework 1.1 Compared . NET Framework 2.0 More widely used, and more convenient to deploy in the future.

 

The hierarchy theory of the system has been widely used. I will not mention it here. This development system is actually divided into two majorProgram(In fact, there are also some small programs, but they are all attached to the two big ones), foreground display and background management control, in order to avoid confusion (sometimes the background usually refersDB ServerIn the future, the front-end display end will be collectively referred toSign-in TerminalThe background management control is collectively referred toManagement Terminal.

The control end is physically a two-layer system and DB , One Application . Currently, the focus is on the sign-in terminal. Because the sign-in terminal is associated with the control terminal, the sign-in terminal must receive the sign-in command from the near control terminal, and the control terminal must collect the sign-in data from the sign-in terminal. Therefore, the system is divided into three parts, namely Client - Application Server - DB Server .

Do You Want To consider client and d B server isolated, this is theoretically more logical, but after a while I finally gave up this attractive idea. If this is the case, you must go to application server It takes considerable effort, although at first the whole system had no time pressure, it could not spend a lot of time and effort on a seemingly beautiful thing. In this way, the sign-in system is regarded as a triangle of "Three L2" from the front-end.

Client

 

Application ServerDB Server

(If not specifiedClientDedicated sign-in terminal,Application ServerDedicated Management Terminal)

 

The overall architecture has been finalized. The following two important issues are considered. The first is what means of communication is used between the check-in terminal and the control terminal, and the second is how to ensure the offline operation of the check-in terminal.

Communication problems can be selected without any worries.SocketThis is also the technical choice of the old system, which is simple and effective.

For offline operation problems, a local database (Local DB. In fact, this is also the practice of the old system, but I am very different from the old system in terms of how to use the local database. The key to successful offline applications is to minimize the impact of offline on the system. For client applications, the difference between offline and offline is not big, or imperceptible.

Reference Offline Application Block But I think it is too cumbersome (in fact Microsoft All Application Block It is too cumbersome for my system) and abandon it. In view of the fact that the most data traffic during the sign-in process is the table that stores the sign-in records, the table that is ultimately concerned. I finally decided to use remote DB Server And Local DB Data Synchronization to isolate and eliminate the impact of offline on the smooth operation of the check-in terminal. Since there is a local database, we can make full use of it. All data access from the check-in terminal will go here. At the same time, open a thread to synchronize DB Server And Local DB When there is a new sign-in record at a certain sign-in terminal, it will be uploaded DB Server And then synchronize it to other sign-in terminals. Local DB . The network is not normal, only this thread is clear, and only this thread is concerned.

Now the system changes from a triangle to a rectangle:

ClientLocal DB

 

Application ServerDB Server

 

From the perspective of the check-in terminal, the system is divided into the following modules:

1, Data access: Client And Application Server Shared (1) For simplicity, DB Server And Local DB The data table structure is consistent.

2, Communication: Client And Application Server Shared (2) .

3,Hardware access:ClientPrivate.

4, Data Synchronization: Client Private. Application Server Only one-minded slave DB Server Retrieve data, it will not know Local DB .

5. UI : client and application server all have.

6,Public module:ClientAndApplication ServerShared.

 

Note: (1) Later, the two did not strictly use the same assembly. Because Client Data Synchronization also requires data access. Because data synchronization requires access to two databases Client You can switch Connection So later Client The data access module is added with a switch. Application Server The version adds a compilation command to disable this switch.

(2),SocketCommunication is different in writing between the server and the client. In actual applications, the check-in terminal and the control terminal send and receive commands, and the two send and receive commands in different ways. At last, the communication modules of the two are not encapsulated into one.

 

This is the last part of the module, and the division of the control module is described in the next part of the module. However, in the following summary (4) I am not going to start the next part of the module, in the order of last year's progress, the check-in terminal should be resolved before the management terminal starts.