In the context of spec / UI / enterprise solutions, I have been mulling over this for some time especially when I play with FXML. To put it in context, I find FXML intriguing and nice. XML metadata that stays completely outside the code and makes it uber flexible to weave in UI to a enterprise solution post facto. The thought trail I have is: Typical Pattern: Model links to Controller that links to a: Customer View ( singleton ? ) Controller links to: Validators / Delegates.. et als.. Model links to in Memory Cache registry { that links to: Persistence Module.. I do not bother about this for now..} In FXML I see nice convention over configuration approach: * XML format.. understood by people/ more importantly editors at large.. * Controller is injectable * all method calls onAction/ events are simple viz #handleSubmitButtonAction or the ilk.. that will thereby call the controller instance methods.. * fxml can also invoke simple ( or complex) javascript action viz: jsSubmitAction( event) Would Spec see that kind of approach.. feasible for extensibility Food for thought more as rethink on fundamental patterns: a) Should view have knowledge explicitly of its Controller.. Or Controller while creating the view injects its instance.. only.. b) Should we push Controller to be a Presenter.. as the case tends to be. And then let Controller be the gateway to all other parts.. as listed above.. c) View actions & callbacks & validators are separated and dealt with a view "controller" , but the gateway to all other parts is handled by a real "observer controller" ... There has to be reliable: * bidirectional update from view -> model ( in cache ) * proper modular segregation of all parts of a standard enterprise app. to enable common and known functions of each part, flexible, scalable but importantly easily maintainable.. in future by developer other than the author.. * Scriptability is one of the desired capabilities with the shrink wrapped app to be extended