There are other methods that been developed since MVC namely Model View Presenters. Here at Martin Fowler's website is a good overview of these patterns.

My own application uses a Passive View as it allows us to rip off a UI and substitute another easily. This an advantage for us as our software is a CAD/CAM application meant to be used with a varity of metal cutting machine.

Our forms are thin shells which call a UI Layer. The forms implement a interface and register's itself with the UI layer. We have a variety of forms used for different purpose. For example a setup form where the user modifies the extensive setup parameters for the machine he using, a shape entry form, a metal cutting form where the user positions the shapes to be cut. All of this forms have a distinct UI.

Also the metal cutting form is different between different type of machine. One may show a WYSIWYG view of a flat plate of metal. Another is a spreadsheet style grid of the parts to be cut in the order they will be cut. Another yet shows the parts positioned on a rotating pipe.

The UI Layer in turns takes the incoming input and executes commands. The commands in turn interact with both the UI Layer, and Model. Nearly everything is handled through command objects as opposed to direct calls through methods.

This structure allows a variety of UIs to be connected to the same model. Within a specific UI a variety of Views can be supported.

The hierarchy looks like this.

• Forms Implement Form Interfaces
• UI Implement UI Inferaces and interacts with Forms through Form Interfaces
• Command interacts with the mode and the UI through the UI Interfaces.
• UI Interfaces
• Model

There are other methods that been developed since MVC namely Model View Presenters. Here at Martin Fowler's website is a good overview of these patterns.

My own application uses a Passive View as it allows us to rip off a UI and substitute another easily. This an advantage for us as our software is a CAD/CAM application meant to be used with a varity of metal cutting machine.

Our forms are thin shells which call a UI Layer. The forms implement a interface and register's itself with the UI layer. We have a variety of forms used for different purpose. For example a setup form where the user modifies the extensive setup parameters for the machine he using, a shape entry form, a metal cutting form where the user positions the shapes to be cut. All of this forms have a distinct UI.

Also the metal cutting form is different between different type of machine. One may show a WYSIWYG view of a flat plate of metal. Another is a spreadsheet style grid of the parts to be cut in the order they will be cut. Another yet shows the parts positioned on a rotating pipe.

The UI Layer in turns takes the incoming input and executes commands. The commands in turn interact with both the UI Layer, and Model. Nearly everything is handled through command objects as opposed to direct calls through methods.

This structure allows a variety of UIs to be connected to the same model. Within a specific UI a variety of Views can be supported. What I have marked as Model could be separate libraries. They would only be combined at the UI Interface layer and above through the UI components referencing the different libraries.

The hierarchy looks like this.

• Forms Implement Form Interfaces
• UI Implement UI Inferaces and interacts with Forms through Form Interfaces
• Command interacts with the mode and the UI through the UI Interfaces.
• UI Interfaces
• Model