The more I think about AudioMan's current architecture, the more I realise it's not suited to model-view-controller event driven action. The old way was lazier -- we had to refresh the GUI explicitly. So I'm thinking about a new architecture that follows the model-view-controller pattern. Let me know what you think about it.

(hand-drawn, can you tell?)

The components are:

1. The SWT/JFace graphical user interface (GUI) view.
2. The models are a subset of the data in the repository that the user wants to view.
3. The mutators are a group of methods that change the contents of the repository, and may indirectly change the models.
4. The formatting component does automatic formatting like capitalization. The files component reads data from the MP3 files.
5. The controller component tells the models what subset of the repository to display. It reads the repository but does not change it.
6. The dB (database) or repository is where all of the data about the user's collection is stored. You can think of this as a SQL-type database if you want.

The interactions fall into two groups: (A) changing the contents of the repository and (B) changing what part of the repository the model displays.

A1. Request to change the repository.
A2. Read files if necessary and check the formatting.
A3. Write the changes to the repository.
[A4. Notify the models of these changes] - forgot this one in the diagram.

B1. View asks controller to load a different subset of the repository into the models.
B2. Get the records from the repository for the subset.
B3. Check the files for changes and check the formatting.
B4. If necessary, update the repository through the mutators.
B5. Controller updates the model.
B6. Model updates the view (event-driven).

I actually forgot something on the diagram: a event-driven link between the mutators and the models. While the GUI is sitting in its current view a record could be deleted, which has to go through the mutators. The mutators could notify the models of these little changes so that the entire model doesn't have to be reloaded by the controller to show the deletion.