The database file contains stop words that should be displayed on the screen by an operator working in a WPF application. As far as I understand from the neighboring answers on the WPF topic, each stop word must be placed in a data object, then this object will be passed to the WPF control through the Binding and will appear on the screen.
Trying to understand what is happening at every step, let's say, the life of the data.
Then I will list what I managed to collect, if there are errors or missing steps, then correct.

  1. A set of bytes from the database is read and transmitted to the WPF application.
  2. A set of bytes is converted to text.
  3. A data object is created and the text obtained in item 2 is copied into it.
  4. Through WPF control, a text object is requested. Not clearly, the text remains type String or will be transformed to Object?
  5. Binding passes the resulting WPF control, where the image is formed and displayed on the screen.
  6. The data object and the text itself are no longer needed and the memory occupied can be freed up.

I would like to understand why WPF has done so and not otherwise? In my opinion it looks somewhat redundant.

  • It looks redundant only if you have a simple application. For example, if you use a binding to pass a single value once, then it may not be so necessary. But if the value you have in the model or in the UI can change, and you need to automatically transfer these changes, you cannot do without the Binding here. And this is just the simplest scenario. - VladD
  • Do you mean that without binding can not do in WPF? But as I understood from the WPF documentation, events are used. As far as I know, the event mechanism, which is basic for .NET, is used in binding, which means that binding can be omitted. - Grizlov
  • Well, you can not use them, yes. But then you have to do all this manually. This is usually no one does, but if you really want, then you can. - VladD

1 answer 1

It's pretty simple - WPF tells you that the display of data should not affect the code, just write the code, convert the data, and the display will work itself. Those. No need to think about how the string will be displayed - it will be a textbox, a textblock, a label, a loaf, whatever - just create a string. Of course, besides primitive types, there are more complex cases, but even here WPF says that you don’t need to be tied up with controls, write classes that support a couple of interfaces - it will be cheap and simple to add a class to such a class without changing the code.

It is worth noting that WPF is basically the Enterprise sector, i.e. healthy and long-lived applications. The cost of changes in them should be minimal and the probability of introducing bugs simply by changing the color \ frame \ distance is generally zero. Therefore, WPF is quite fundamentally different from WinForm - no static dimensions of controls, no attachments to numbers - everything is adaptive, a lot of problems such as styles / triggers, so that the behavior does not need to be programmed manually.

Of course, there are some downsides. When the application is a couple of thousand lines of code, it becomes quite difficult to find the cause of the visual bug, because there are about 10 different data sources for any WPF control property. Therefore, various frameworks appear, on the one hand, simplifying the creation of uniform views, on the other hand, implicitly imposing restrictions on the use of WPF buns in order not to create hell.

And now, by what you describe. dotNet uses links for classes, which means in the simplest case a class read from the database contains N fields of primitive types. As a result, the class either directly or through the wrapper goes to the WPF controls, taking up exactly the same amount of memory, for where you just need to put a reference to the instance, and not create a new one. In the case of a string, it is either displayed directly, i.e. There is one instance at all, or one duplicate is created at the view mode level in which MVVM is responsible for displaying / changing data.

It is worth noting that string data is cheap. If you are certainly not trying to display "War and Peace." If you climb inside WPF, then the display will be redundant, because for every user of the user there are quite a few MBs. If you do not have display problems right now (lagging animation, loss of controls, blinking) and memory (OutOfMemory, clogging of a swap) - it's easier not to think about it. And when they appear, everyone will have to take a profiler in their hands and look for the cause of the leak, and not to wonder if I have lost a couple of extra bytes in the bindings.