0

Imagine, if you will, a data construct that looks like this:

public class FolderThing
{
    public long ID { get; set; }
    public virtual ICollection<FolderThing> folders { get; set; }
    public virtual ICollection<FileThing> files { get; set; }
}

public class FileThing
{
    public long ID { get; set; }
    public string filename { get; set; }
    public string filesize { get; set; }
}

This is strictly provided as an example, and has little to do with my target structure, but it serves to illustrate the problem using a metaphor we should all be familiar with. Yes, I know, backing stores.

The structure is set up to be persisted using Entity Framework (EF6, specifically). As you can see, the depth of the structure is arbitrary, in that a FolderThing can contain multiples of itself, ad infinitum. I also want to be able to export a single FolderThing and all its children as an XML file that looks something like this:

<folderthing id="123456">
    <files>
        <filething id="456" filename="foo" filesize="125987">
        <filething id="457" filename="bar" filesize="125900">
        <filething id="458" filename="foobar" filesize="126987">
    </files>
    <folders>
        <folderthing id="123">
            <folderthing id="124">
                <files>
                    <filething id="466" filename="oof" filesize="125987">
                </files>
            </folderthing>
        </folderthing>
    </folders>
</folderthing>

Some time ago, I asked how to serialize an ICollection, and that answer led me to use the DataContractSerializer. Then I asked this question, and received a helpful answer that only ran me into the problem I'm presenting here. So, how do I fully serialize a data structure that uses ICollections heavily to create an arbitrary-depth object?

Community
  • 1
  • 1
J.D. Ray
  • 697
  • 1
  • 8
  • 22
  • Does your graph have any cycles? Is any object the child of more than one other object? – Servy May 01 '15 at 18:47
  • How is this question related to EF? What you do with this once you serialize it doesn't really affect how you go about serializing it. – Servy May 01 '15 at 18:48
  • I don't understand what you mean by the first question, however the answer to the second is "not usually, though sometimes", if that's at all helpful. At some level of depth, it's possible for an object to run into itself, which I'll have to be mindful of, putting in a trap to stop digging at that point. – J.D. Ray May 01 '15 at 18:50
  • It's only related to EF in that the structure is set up that way so that EF works. If the answer includes "don't use an `ICollection`, then its not useful. – J.D. Ray May 01 '15 at 18:52
  • Then you do have cycles, and that makes it quite a lot more complex to serialize. You won't be able to structure it as a tree as you have in your example. You'll probably need to serialize it all using custom code; I wouldn't expect any built in serializer to have support for cyclical models. – Servy May 01 '15 at 18:54
  • How about if the object I'm serializing is exactly as the example shows? – J.D. Ray May 01 '15 at 18:55
  • That would make it easier, yes, but as you've said neither of those restrictions actually applies, and building a tool that *does* support them would involve a radically different approach, such an answer wouldn't actually help you. – Servy May 01 '15 at 18:56
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/76727/discussion-between-j-d-ray-and-servy). – J.D. Ray May 01 '15 at 18:59

0 Answers0