Resources in .Net == bean factories in spring?

I was reading through MSDN documentation yesterday and it struck me that the Resources feature in XAML is actually a bean factory in the world of spring. It looks different, but the idea of storing objects defined in XML and making that accessible, and having hierarchical contexts was pretty much like spring. It makes you realize that using spring at a more fundamental level inside of RCP applications could be a good idea. The hierarchical contexts appear to be automatically assembled based on the scope of the resources e.g. Windows.Resource versus Page.Resource I believe are automatically nested.

On a separate note, DataContext looks to be the same as a hibernate Session although .Net DataContext has more support for data binding and other features. The DataContext provides identify scoping boundaries, has connection information, etc.

The real issue for the eclipse RCP is that the jface GUI elements do not allow more lifecycle control when defined in the plugin extensions. The plugins often define a class attribute for a specific configuration element but you cannot control when and how that element is created. Typically, it would be desirable to create this element in a context like spring's so we could achieve XAML-like programming environments.

Interestingly, when working with binding, specifying static versus dynamic resources is much like specifying a FactoryBean in your context versus a direct resource specified in XML. Its not an exact analogy though because a StaticResource in a Context or Resource is not suppose to change at all but in a spring context, you can retrieve the bean in a context and programmatically change it in code.

The DataContext also acts as a PresentationModel design pattern. In fact, the DataContext typically holds data specifically targeted for the GUI. Note that a DataContext is typically part of the general Resources context although I have not seen explicitly how this is autowired.


Popular posts from this blog

zio layers and framework integration

typescript and react types

dotty+scala.js+async: interesting options