Using navigation properties in entity framework code first -
context:
- code first, entity framework 4.3.1;
- user ---- topic, 1 many relation;
userpublic virtual icollection<topic> createdtopicsnavigation property(lazy loading);topicpublic virtual user creatornavigation property;dataservicecontroller : dbdatacontroller<defaultdbcontext>, web api beta, asp.net mvc 4 beta , single page application;- system.json json serialization;
web api action:
public iqueryable<topic> gettopics() { // return dbcontext.topics; // ok return dbcontext.topics.include("creator"); //with exception }result: "an unhandled microsoft .net framework exception occurred in w3wp.exe"
the problem here seems be: should not add navigation property in both entities(cause circular reference?), , if delete createdtopics navigation property in user class, ok again.
so, in similar context listed above, here questions:
- how deal navigation properties in situation of 1 many relation;
- further more, how many many relation, have divide 2 1 many relations;
- what best practices , precautions of using navigation properties?
i have read many related posts, still not clear enough :(,
thanks help!
dean
this not problem of code first or ef - problem of serialization. serializer used convert object graph representation passed in web api message not able work circular references default. depending on message format want use web api uses different serializers default - here more default serializers used web api , way how change it. following text suppose using datacontractjsonserializer or datacontractserializer (should default xml serialization) same possible json.net (should default json serialization - json serialization can switched datacontractjsonserializer default serializer better).
so can do? can tell serializer should track circular references marking classes datacontract(isreference = true) , each passed property datamember attribute (check linked article description how achieve json.net). allow serializer correctly recognizing cycles , serialization in theory succeed. in theory because demands not using lazy loading. otherwise can serialize more data expected (in catastrophic scenarios can lead serializing whole content of database).
when serialize entity graph lazy loading enabled serailze topic , creator serialization visit createdtopics property => related topics lazy loaded , processed serialization , serialization continues visit creator of newly loaded topics! process continues until there no other object lazy load. because of should never use lazy loading when serializing entities.
other option exclude reference serialization. need serialize creator. don't need serialize createdtopics can mark property ignoredatamember attribute (jsonignore json.net). problem if have web api action returning user createtopics not work because of attribute.
the last option not using entities. option used in web services create special dto objects satisfying requirements specific operation , handle conversion between entities , dtos inside operation (possible of tool automapper).
there no difference between handling one-to-one, one-to-many, or many-to-many relations. if have navigation properties on both sides must deal problem.
Comments
Post a Comment