Before I start to talk about the Clear method, a little correction to the code I published yesterday.  I am effectively obtaining and closing an ObjectContext with each DAO call.  This is extremely inefficient, and i probably want to change it in future so that the Context is opened once per thread, but I'm going to leave it as it is for now.  It does mean that I should Detach any entities from the ObjectContext before returning them, as an entity keeps a back pointer to it's ObjectContext, and it can't be attached to more than one at a time my DAO would start throwing exceptions the minute you started using it properly.  

So why is deleting objects so difficult?   Essentially it isn't if the object graph is attached and fully built, you issue a DeleteObject and the entity and the relationships are flagged as deleted, any related entities that have Cascade delete rules will also be flagged as deleted(and when you issue SaveChanges the rows will be removed from the underlying store).  But in our DAO the objects are being sent to is in a Detached state, which means you have to rebuild the object graph in order for the object to be deleted - If you don't you'll end up with either orphaned records in the database, or you'll throw Constraint exceptions.

There are many approaches to building the Object Graph back up, for instance DannySimmons has a blog posting about this.   Unfortunately, while Danny's method is cool it doesn't work in a disconnected scenario very well (try to reason why.  Here's a big hint, will the ObjectSateManager contain values for detached objects?), or for my scenario, which is to work with any entity (I do have a generic DAO after all). 

So I know to get hold of the relationship information for any entity, and while I'm sure there may be easier ways i just grabbed the attribute values from the EdmRelationshipAttribute which is added by the EDM generator.  This lists all the relationships across all Entity Containers and all Entity Sets, so i need to know which Entity container and Set I'm working with, so I've modified the constructor to pass these in.

Once I have the attribute names it's a fairly straightforward matter to test if the entity I'm passing in is involved in the relationship.  I was even toying with writing a Linq query, then decided against it ;-)

RelationshipManager rm = relations.RelationshipManager;   
foreach (EdmRelationshipAttribute attr in attributes) 

{ 

     // The relationship may not exist for this entity 

     // as it may be for another entity set 

     try 

     { 

         rm.GetRelatedEnd(attr.RelationshipName, attr.Role2Name); 

     } 

     catch 

     { 

         // do nothing 

     } 

} 

re = rm.GetAllRelatedEnds();

Now all you have to do is load the related objects into the ObjectContext.  If you have these entities, you could simply attach them to the context, and then add them back in to the related end, in my case I went for the expensive option (but always guaranteed to work) of loading the object graph by issuing Load().  Now you can safely delete the object

foreach (IRelatedEnd related in re)  
{  
     related.Load();
}

There is only one problem to solve now, how do I get every object in the EntitySet?

I'll leave you with that little puzzle, but think Linq :-)