How should nested components interact with model in a GUI application?

Broad design/architecture question. If you have nested components in a GUI, what's the most common way for those components to interact with data?

For example, let's say a component receives a click on one of its buttons to save data. Should the save request be delegated up that component's ancestors, with the uppermost ancestor ultim开发者_如何学运维ately passing the request to a controller?

Or are models/datastores in a GUI application typically singletons, so that a component at any level of a hierarchy can directly get/set data?

Or is a controller injected as a dependency down the hierarchy of components, so that any given component is only one intermediary away from the datastore/model?

---

My first thought is to define a singleton data-layer API, which is callable by GUI components.

If you want multiple instances of the data then give out 'handles', which can be stored by GUI components, and passed in to the data layer to get data out again.

This idea is similar to, for example the file system API; or an SQL server API; or any O/S API.

---

Generally, there are few possible options to operate with nested components:

• Nested component uses the same model as root component / Nested component uses its own model.

• Nested component interacts with the same controller as root component / Nested component operates with its own controller.

There is no single correct answer what option to use. Of course, using the same model and the same controller is simplest way, but if nested component contains complex UI logic, it is better to separate model or/and controller.

Also, what language do you use? What platform? In different programming environments different implementations are better. If you use platform supports object-oriented component-based GUI model, you can incapsulate nested control into the user-control, and get reusable encapsulated easy-to-use component.

I think using singletons for model/controller is bad idea, espesially you using language with garbage collector. Using singleton is simple, but what if you need second instance of nested control on the root view?

---

I agree with STO above:

• Pushing data to an underlying controller / viewmodel, which is shared with the C / VM of the parent view is what I do in most of my apps.
• Having singletons is a bad idea! If you believe you need a singleton, you can achieve the same result by making a call to a Factory that caches instances. E.g. factory.GetAcountViewModel();
• I wouldn't delegate the handling to the parent - in general. That reduces the testability of the code, since now you are passing data and state through the UI layer.

Just an FYI: If you are up for some additional reading, you may also want to check out http://compositewpf.codeplex.com, which solves the generalized problem of composable UI.