Maybe I'm not understanding the post, but doesn't it seem silly to go to such lengths to return a list of orders for a given customer? I mean, it looks like your code using recursion, reflection, and generic invocation...is there some reason you couldn't have done this? http://msdn.microsoft.com/en-us/library/bb896249.aspx If I've missed something important, I apologize, but your post doesn't seem to really explain why you had to go to such great lengths.
yes I would like to go into such great length because I want to backup the object Graph into a backup file and later on it will be attached to database that might be the same database or to another database one with same schema.It will not override existing one if that any data of an object already exist , if not then it will insert the object will related object.
Thanks for getting back to me. So if you just need to serialize the objects, are the built-in serialization methods not sufficient if you've loaded all related entities using the method in the link I put in my last comment? Here's the MS doc on binary serialization with EF for example: http://msdn.microsoft.com/en-us/library/bb738528.aspx Could that method work in this scenario if you had the object graph loaded by disabling lazy loading?
(PS: Sorry for not directly replying to your last comment, the comment system is giving me difficulty this morning)
Thanks for the link and great suggestion. But I am not sure , some days ago I read something : Because POCO entities do not have the same relationship requirements as objects that inherit from EntityObject, a slightly different process is required to load related objects. For general information about loading related objects, see Loading Related Objects and Loading Related Objects.