<image source= "{Binding elementname=lboximages, path=selecteditem.source}" is often seen in the code/> or
<wrappanel orientation= "Horizontal" width= "{Binding relativesource={relativesource mode=findancestor, Ancestortype={x:type ListBox}}, Path=actualwidth, Converter={staticresource subconverter}, converterparameter=10} "/ The > example is not very familiar with the binding usage and the principle, so learn more in depth:
The essence of the program is the Data + algorithm. Data flows between storage, logic, and interface three layers, so it's important to stand on the data point of view, three layers. But the distribution of the algorithm in the 3 layer is uneven, for a 3-layer structure of the program, the algorithm is generally distributed in these places:
A. Inside the database.
B. Reads and writes back data.
C. Business logic.
D. Data presentation.
E. interface and logical interaction.
A, b two parts of the algorithm is generally very stable, will not be easy to change, the reusability is also very high; C with the customer needs the most closely, the most complex, change the most, the large number of algorithms are concentrated here. D,e is responsible for UI and logic interaction, and also occupies a certain amount of algorithm.
Obviously, the C part is the core of the program, is the most important development, so we should focus on the C part. However, the two parts of d,e often become a source of trouble. First of all, these two parts are closely related to logic, it is possible to accidentally put in the logical layer of the algorithm written into the two parts (so there is the MVC, MVP and other modes to avoid this situation). Second, the two parts communicate with the logical layer in the form of messages or events, and once the same data needs to be displayed/modified in more ways, the code used for synchronization is complicated; Finally, D and e are mutually inverse pairs. But it needs to be separate to write-----display data write an algorithm, modify the data and then write an algorithm. In short, the result is that D and e two parts will take up a part of the algorithm, do not get involved in a lot of energy.
The root of the problem is that the logic layer and the presentation layer are not fixed------when the customer needs are fulfilled, the logic layer is indeed at the core. But in the implementation of the UI, the presentation layer is at the core of the position. WPF as a professional presentation layer technology, gorgeous appearance and animation is only its surface phenomenon, the most important thing is that he in the depth of the programmer's thinking fixed in the logic layer, so that the display layer is always in the subordinate position of the logical layer. The key to WPF's ability to do this is the introduction of the data binding concept and its accompanying dependency property systems and DataTemplate.
From the traditional WinForm to WPF, for a three-tier program, the data storage layer consists of a database and a file system, and data transfer and processing are still used. Basic classes such as NETFramework's ADO (as with WinForm development). The presentation layer is implemented using the WPF class library, and the presentation layer and the logical layer communicate using Data binding. It can be seen that the role of Data binding in WPF is the role of highways. With this expressway, the processed data is automatically sent to the user interface and displayed, the user's modified data will automatically return to the business logic layer, once the data is processed and will be sent to the interface .... The logic layer of the program is like a powerful engine that has been working, displaying the data in the form of a processed data-driven user interface as well as text, graphics, animations------This is the data-driven UI.
After the introduction of data binding, the D,e two parts are simplified. First of all, the data in the logical layer and user interface straight to go, do not involve a logical problem, such a user interface part basically does not include the algorithm: the data binding itself is two-way communication, so the equivalent of D and e into one; For multiple UI elements to focus on the same data, just use the data The binding associates these UI elements with data one by one (a data-centric star structure), and these UI elements display this change synchronously when the data changes. The problems mentioned earlier have been solved. More importantly, after this optimization, all business logic-related algorithms are in the business logic layer, the logic layer becomes a self-running, complete system, and the user interface does not require any logic code. Fully dependent and subordinate to the business logic layer. There are two obvious benefits to this, first: if you look at the UI as the skin of the application, and think of the storage layer and the logic layer as the pulp of the program, we can easily tear the skin down and replace it with a new one. Second: Because the data layer can operate independently, we can do better unit testing without the help of UI Automation testing tools----You can think of unit tests as an "invisible UI", and unit tests just use this UI to test business logic directly around the real UI.
WPF binding< > Data binding status in WPF