Can I use a C# collection to hold class instances with self-referential relationships?

Question

Hi,

I need to model in memory a collection web files, but that relationships between them. That is file A (e.g. html) may have a link to file B (e.g. css) and file C (e.g. javascript). Also file D may also require file B. If I wanted to delete file A I would need to make sure any files it uses (e.g. file B) is not also being used by another file (e.g. file D). Perhaps something like:

  List<WebFile> list_of_webfiles

  public class WebFile
  - string url
  - bool parentFile

  public class FileRelationship
  - private WebFile parentWebFile;
  - private WebFile childWebFile;

QUESTION - What would be the best way to model this in C#? (e.g. which collection type & how to model)

Note - it has to be modeled in memory (no database), and I need to be able to serialize to XML too to save. An example of what I mean would be something that looked like this...

        XmlSerializer serializer = new XmlSerializer(typeof(List<WebFile>));
        TextWriter textWriter = new StreamWriter(CONFIG_FILE_PATH);
        serializer.Serialize(textWriter,  list_of_webfiles);
        textWriter.Close();

Thanks

Answer 1

This seems to imply a hierarchical 'tree' relationsihp where you may have

Class WebFile:
- URL : string
- Parent : WebFile
- Children : WebFile[] (could be a list depending on the need)

Then somewhere you have a

List<WebFile> webFiles;

This approach makes it easy to traverse the tree of webfiles and find the related ones, but harder to list all the files themselves.

Alternatively, you could store the list of files and relationships seperately

Class WebFile
- URL : string

Class WebFileRelationship
- Parent : WebFile
- Child : WebFile

And you have 2 containers

List<WebFile> webFiles;
List<WebFileRelationship> relationships;

This approach makes it easy to list all the relationships or all the files, but hard to determine the individual relationships.

It all depends on your application, do you need more information about the individual files or the relationships?

Answer 2

The fact that you have duplicates (in terms of multiple files requiring B) means that it would be a pain to use the most obvious "requires" structure as a tree, since that would involve nesting B multiple times (from different parents). A few options:

• keep the object-references in the object model, but only list the name (or some other reference) in the file; relatively simple to do, but requires fixups after deserialization
• only list the name (or some other reference) in the relationship, and mirror this in the object model - i.e. "file.Parent" is a key, not another object
• have the full object model, and use a graph serializer, such as DataContractSerializer with preserve-object-references enabled

I would probably choose between the last two; the last has "not very pretty" xml, but is relatively simple to implement. But I'd be tempted to just use the middle option, and have just the key references in the object model, i.e.

[XmlType("file"), XmlRoot("file")]
public class File {
    [XmlAttribute("name")]
    public string Name {get;set;}
    [XmlElement("ref")]
    public List<string> References {get;set;}
    public File() {References = new List<string>();}
}

maybe not pure OO, but simple to do. Also - avoid the need to duplicate data; if you store it just like the above, you can always scan to see "what uses this file" (with some indexing if you need). But trying to maintain relationships in both directions (i.e. "UsedBy") is a nightmare.