GUI and Implementation Separation

[thegrovesy]

Hi all,

I am in the process of creating a music library, and want to keep the different layers of implementation separate. My current plan, and understanding has my application divided up like this:

1. GUI Layer, talking to...
2. Music object (and implementation) Layer, talking to...
3. Data Storage Abstraction Layer, talking to...
4. Access Database

I understand and agree with the reason for doing this (I.e. I can change any one of these with little or no impact on the other layers). However as I implement this (parts 2,3 & 4 close to completion) I see an issue that I can't quite get my head around...

From the database the Music Object Layer creates an Album object for each album it finds, and within each Album object it will create several Track objects (I have around 30GB of music). Although all the information held about each it purely text my Album Handler Object (which holds all the Album objects) will still get pretty big.

Now, at some point my GUI Layer will need to access this list of Albums to display cover art and other information about each on the screen!

So my question is how should the GUI get the Album information?

Originally I planned to copy the Album Handler object to the GUI, but this might not be a good idea if this object becomes massive! Another way could be to get the GUI to called the Music Object Layer(MOL) with an Album Handler pointer (sorry im originally a C programmer) and then the MOL could create the album objects there (In the GUI layer instead)??

Anyway, what are peoples thoughts on this? How have other people tacked this problem?

Many thanks

[macu]

There's a few ways you could approach this issue. One option would be to have a lightweight album class that has e.g. a thumbnail of the album cover, an artist and title and a track count. You then create a collection of these and display them to the user in your UI. When the user wants to load a specific album, only then do you load an actual Album object with all track names, lengths, the full sized album cover, etc. It's not really a good idea to load all albums fully when the user may only browse a few and then close the app.

Another option is to keep what you have but use "lazy loading", basically you would have an album class that when loaded only loads, thumbnail, artist, title, track count. When the user then wants to view the album properly you load everything else. This can be done via property get's (i.e. if the app accesses the full album cover and it's not loaded, then you load it). Or you could have a method which does everything in one hit, e.g. Album.Open or something which would load album cover, all tracks, etc, etc.

The approach you take is partly dependant on how you feel about having multiple views (classes) of the same entity within your system. The first approach means having e.g. AlbumLite and Album classes which some people don't like. However, all of the important code is in Album as AlbumLite would just be a read-only view of the data.

HTH