3 QAbstractListModels versus 1 QAbstractItemModel

This is a simplified representation of the existing data structure I have in my code (The actual data structure is composed of classes), the data of which I need to display and modify via multiple views:

Code:

---

struct StopData {
    QString name;
    int id;
    QList<Amenity> amenities;
    ...
}
 
struct Amenity {
    QString name;
    int id;
    ...
}
 
struct Route {
    QString name;
    int id;
    QMap<Stop, StopData> stops;
    ...
}

---

A QList<Route> of Route objects is owned by a RouteManager class which be responsible for the data and any models wrapping around it.

As you can see, the hierarchy and relationship between the objects is cleanly and explicitly defined. The data is effectively a tree, albeit a constrained one with a fixed depth and specific objects at each level (e.g it wouldn't be valid to have Route as a leaf node to Amenity, etc).

I'd like to have 4 list views, each serving a different purpose. View 1 works independently, while 2, 3 and 4 are interrelated.

Code:

---

View 1:
 
This should be the "overview" list that shows each Route and an overview of the data contained within in it. I haven't yet decided what data it's going to display, but it could be anything from the Route's list of Stops, Amenities, etc. Basically anything the Route object has access to via its members
 
View 2:
 
This is a simple list of all Routes by name.
 
View 3:
 
This is a list of all Stops under a Route selected in View 2. It should be possible to add, modify and remove Stops to the Route via the view and accompanying add/remove buttons. 
 
View 4:
 
This is a list of Amenities under a Stop selected in View 3. It should be possible to add, modify and remove Amenities to the Stop via the view and accompanying add/remove buttons.

---

What is the most appropriate way to expose my data to the views? Somebody suggested having three QAbstractListModel subclasses, one for Route, one for Stop, and one for Amenity, passing in a pointer to the RouteManager's list of Routes. When a selection is made, notify the models (probably via signals) of which Route, Stop or Amenity have been selected so we can locate the correct item. I'm not sure I'm on board with this idea as it creates a tight coupling between the three models and could potentially result in synchronisation issues. Additionally, what if we display something in View 1 (e.g. the first Stop and that Stop's first Amenity), that is then modified via the other view? Well both views are using different models, so even though the underlying data has changed, one model would have to notify the other that the data at a specified position has changed. I can see this very quickly becoming a bit of a tangled mess...

The other option is to wrap a pointer to my QList<Route> routes in a subclassed QAbstractItemModel, so the data is accessed and modified in only 1 place. I could then have 4 proxy models, one for each view, to expose the data as lists to the views. In a way this seems like the cleaner solution, but it's quite hard to make a QAbstractItemModel work with existing data. I don't really want to be modifying my existing structures to subclass from a common base "TreeItem" class, etc. Anyhow, if anyone thinks using a QAbstractItemModel and proxy models is viable, I'll explain how I was going to approach it. Otherwise, keen to hear other ideas! Thanks.