Shulou(Shulou.com)06/01 Report--

In order to solve some tedious problems in the work, a GUI program is written, and the interface looks like this.

The implementation of this program is not very tedious, but in the interactive operation of the interface, it is not just to show the data. As you can see in the picture above, every data item in the list needs to be filled in and selected; records need to be added and deleted; records need to be repositioned; move up and down; and to achieve these operations, the program to control UI is actually quite complex.

I finished the program and took it to my colleagues to demonstrate how to use it. My colleagues gave me a lot of suggestions. One of them is to divide the interface into upper and lower parts to replace the selection of type fields in the list to simplify the interactive operation, that is to say, after simplification, the interface of the program will look like this

Students who write code for a living must know that the implementation of the changed requirements is not a pleasant thing. Although the colleagues who give me suggestions are not on the demand side, I have to consider some of their opinions, and I have to admit that in terms of the convenience of software operation, the opinions given by my colleagues are indeed much stronger than before. But if you really want to modify the program in this way, you can put yourself in your shoes. If the program was developed by you, would it be a very laborious thing to make such a change? It is inevitable that a large number of code logic changes or copy the code so that the UI interactions of the two lists on the interface do not conflict with each other and do not affect the correctness of the results, even in extreme cases, it is unknown that the structure of the whole program will be changed. As soon as the sound suggested by my colleagues came into my ears, I thought it was impossible. My first reaction was to retort immediately and say it was an impossible task.

Afterwards, I settled down to think about it. First of all, the suggestions of my colleagues are completely reasonable, except for the difficulty of modifying the program, I can not find a suitable reason to refuse; second, I recall the way I wrote the code logic of this program. I found that it didn't seem to take much effort if I wanted to modify the program as suggested by my colleagues, and it could be said to be very simple and incredibly simple. I followed the plan generated in my mind, and it only took me about 15 minutes to complete the task, achieved the specified effect, and only modified five or six lines of core business logic code. I was surprised that the changes in interface and operation were not proportional to the workload and code changes at all. In the process of revision, I roughly did the following things

Changes to the interface

1. Resize each component in the interface to free up a blank area for the second list

two。 Copy a copy of the xaml code from the first list to the location that has just been vacated. This xaml code is a ListView control, so you need to give it a new name.

3. Make a copy of the "add an item" button in the upper right corner of the interface, place it above the second ListView, and bind a new event

Changes to the program part

Bind a data source for the new ListView

two。 Bind the event code for the new add an item

And then, it was done, and it was as simple as that.

Some students may ask: "if nothing else, where is the event code for deleting, moving up and moving down the second list?" are you fooling us as rookies who haven't written the code? " As a matter of fact, there is this code, which reuses the event code of the previous list. "but why is the event code for the previous list transitioned to the new ListView without change? it's not in line with conventional programming logic." it actually has something to do with the way my program code is designed.

You can see that there are many interface interactive functions in the interface of the program, such as add, delete, move up, move up, as long as the mouse is clicked on these buttons, the interface will change immediately, which is bound to control the interface elements through the program. This program is developed in C # and XAML, but for audience reasons, I use JavaScript and html as an example. If we need to remove an item in a table, then we must manipulate the html table through the document object model, for example, by removing it.

Var ele = document.getElementById ("table row ID")

Ele [XSS _ clean] .removeChild (ele)

The same is true for adding one to the list, and it is the same for moving list items up and down, but it is more difficult and complex to implement, but these are all conventional implementation ideas.

However, I did not implement the WPF GUI program in this way. For example, when we develop Web applications, it is most common to display data in the form of lists. When we want to delete a piece of data, the way not to use ajax for non-refresh deletion is to delete the data first, and then refresh the page, and the data that needs to be deleted will be removed, both the database and the interface. The advantage of this method is simple logic, to refresh the page instead of JavaScript operation DOM to update the interface; the disadvantage is poor experience, there is no way to update the page without refresh. Other operations on the page can also update the UI in the same way. After the records are inserted into the database, the page will be refreshed, and the data displayed on the interface will be increased. After modifying the sorting number of the records in the database, the corresponding data items on the back boundary of the refresh page will also be transferred to the corresponding location.

I borrowed the programming idea of this browser / server architecture to simplify the problem, omitting all kinds of program operations of dynamically updating UI, and updating UI only when ListView binds data. The core idea of my design of this is as follows

1. Create a new list data structure to store the content displayed in the ListView control

two。 Insert a piece of data into the list structure during the add operation, and then re-bind the data to ListView to re-render the interface. All add operations are performed in this way, updating the data structure before rendering the ListView

3. The delete operation is similar to the add operation, removing the data item from the list data structure and then having ListView redraw the UI based on the data source

4. The same is true of other operations with UI

All the operations that need to be done on UI are transferred to operate on the data, and then redraw the UI according to the results of the data being operated, the advantage of this is that the logic of the code becomes clear and simple, except that you need to pay attention to the logic related to UI when mapping the data into the interface, other times only care about the data, and the difficulty of manipulating the data structure is obviously lower than that of the operation interface elements. The disadvantage is that after each interactive operation leads to a change in the data, the UI needs to be completely redrawn, affecting the user experience. This impact is obvious for Web applications because a http request needs to be performed to refresh the page within the browser. For windows GUI applications, this gap in experience is almost difficult to observe with the naked eye, the data is read from memory, without any network overhead; and the time to redraw the interface only takes a few milliseconds or less, so there is no reason to pay attention to these issues that will not affect the use of the software at all. We should focus on substantive issues such as how to simplify the code and how to improve the availability of the software.

My program is implemented with this design idea, and when I apply my colleagues to promote the suggestion to modify the program, generally speaking, I have done two things.

1. Modify the interface and add an additional ListView control. The structure of the two controls is exactly the same.

two。 Split the original large piece of data into two pieces and bind them to two ListView

Modify to

So wayward and done.

Most of the time, we always complain that the change in demand has led to an increase in our workload. whenever we hear the news that there is a change in demand that we need to overhaul the program, we are as excited as hearing that our girlfriend has run away with other men, thinking that everything needs to be reversed and all the efforts are wasted. In fact, however, the code logic is organized skillfully enough to minimize the impact of changes in requirements on code changes. Every professional programmer should have the ability to "cope with change". Our time is limited and precious, and writing stupid code that takes a lot of time to maintain and can't cope with change is a chronic suicide that wastes time and life, so you can never be wrong when writing code.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.