Nowdays I cannot understand at all how the persistence ignorance could be applied with entity framework. I've a classic repository and unit of work design by using entity framework.
Now, imagine a simple client side scenario where I need to read some object list, and later saving one of them. My entity contains some object graph, for instance, the Person entity coontains Address complex property where Addrress is another entity and also a list of Hobby objects, where it also is another entity. My client:
var personList = PersonRepository.GetAll();
PersonRepository.Dispose(); // it will dispose EF's ObjectContext
var person = personList[0];
person.Address.City = "...";
person.Hobby.Remove(person.Hobby.First());
PersonRepository.SaveChanges(person);
As you can see, I've mantained the persistence ignorance logic, I'm limited to use person object only and its boundaries, however, in real world, tha above code snippet will be inclined to fail for detach object beacuse I've disposed the unit of work.
So, I've thought to use some entity wrapper with some method like ManageGraph(object obj, ObjectState state) in order to preserve any other change in a internal dictionary for all relations changed. However, I don't like this solution, it seems too dirty and looks like anty pattern:
person.Name = "some name";
person.ManageGraph(AddressObject, state.Modified);
rather then
person.ManageGraph(AddressObject, state.Added);
But...Where is the persistence ignorance? Why I'm enforce to use bad tricks in order to get the right work? Persistence ignorance means that I must treat the simple object without any other stuff, so it would be like following:
person.SomeProperty = SomeValue
person.ComplexProperty.OtherProperty = otherValue
person.ListOfComplexProperty.Add(new entity);
For sure, I know, I don't want the magic solution, it doesn't exist, but, is there some good solution or suggestion to get best work?
