A very simple demo application demonstrating the general principle:
TModel = class
property ValueList : TList <Double> read ... write ...;
end;
You could then have multiple views that visualize the model, i.e. one view that displays the values in a table and one that displays the values in a diagram:
IView = interface ['{0D57624C-CDDE-458B-A36C-436AE465B477}']
public
procedure Update;
end;
TTableView = class (TInterfacedObject, IView)
private
FModel : TModel;
FController : TController;
public
procedure Update;
end;
TDiagramView = class (TInterfacedObject, IView)
private
FModel : TModel;
FController : TController;
public
procedure Update;
end;
The views do only read data from the model. All interaction with the GUI is delegated to the controller class (which uses the Observer design pattern by the way):
TController = class
private
FModel : TModel;
FViewList : TList <IView>;
private
procedure UpdateViews;
public
procedure AddDataValue (Value : Double);
end;
The implementation of AddDataValue could look something like:
procedure TController.AddDataValue (Value : Double);
begin
FModel.ValueList.Add (Value);
UpdateViews;
end;
procedure TController.UpdateViews;
var
View : IView;
begin
for View in FViewList do
View.Update;
end;
This way you achieve multiple things:
- You can easily use multiple views (either allow the user to switch beetween views, or show them simultaneously)
- All data is in the model and completely separated from the presentation. Change the representation, change nothing in the model.
- To implement persistance you only have to save the model.
- You could use the controller to execute all necessary checks. (Instead of implementing this for each view)
For a complete list of advantages, the web is full of discussion of the MVC pattern and its alternatives.
In Delphi applications you may find that the controller is kind of overhead because of the event-based programming style in Delphi. What I often do is to only split my application into model and view.