The problem is to develop both aspects of the application, GUI and domain logic, independently from each other since the domain logic often has to be reused for instance with other user interfaces while the GUI often needs to be maintained w.r.t. latest options of new operating systems, platforms, multimedia capabilities etc.
Another issue is the complexity of modern user interfaces as well. On the one hand, dependencies between different controls within the same user interface become more and more complex. A selection here causes a selection there, leading to a changed list of options at a third place, and so on and so forth. Consistent update strategies for such controls that are strongly linked due to the visualized domain knowledge are hard to develop. To make things even worse, many applications require more that one user interface for the same purpose. The complexity of the developed user interfaces forces system designers to adopt them to different types of users, that cause sometimes similar actions in the system but have a completely different view on the underlying domain logic.
wx.NET is connected either to the wxWidgets framework as well as to Microsoft's .NET world that both provide capabilities to more or less separate view layer and application/domain layer.
wxWidgets provides on the one hand the wxValidator class and its derivations. On the other hand, complex dialogs like the grid and the list control provide specialized interfaces to a domain model. Both means can be used like a glue between application and user interface since they usually achieve a consistency between both offering a standard set of events to cause updates of the other side.
The .NET world uses the term data binding to express the purpose to offer building blocks connecting view to application like binding lists and binding sources. However, these implementations lack a clear concept. There behaviour is often hard to predict.
Therefore, wx.NET comes with its own component model, that, however, borrows the best from validators and bindings. The idea of wx.ComponentModel is to provide classes representing standard models for the data and the controls, that provide standard events and interfaces. These models can be plugged together to represent the logical dependencies between them. In such a way, a list control can be programmed to react on the selection in another list without knowing it directly: It knows the relation to an appropriate view model that is linked to the model of the changing list. Thus, only one piece of code knows this relation: The code that builds the configuration of models that represents this dependency. Dynamic interdependencies are represented as a static configuration. This can make things easier.
(c) 2003-2011 the wx.NET project at