Klonen van zelfsturende entiteiten in EF 4.0?

Hoe kan ik een Self-Tracking Entity Graph klonen in EF 4.0?

Bedankt

0

2 antwoord

Self-tracking entiteiten zijn serialiseerbaar, dus de eenvoudigste manier om een ​​diepe kloon van de entiteit te krijgen (diepe kloon = kloon van de grafiek) is om DataContractSerializer te gebruiken en te serialiseren en onmiddellijk te deserialiseren. Gedeserialiseerde entiteit zal uw kloon van de grafiek zijn.

1
toegevoegd
@Merlyn: dit gebeurt niet voor echte STE's omdat ze lui onderdak niet ondersteunen om precies dit probleem te voorkomen. Met POCO's moet u proxycreatie uitschakelen om dit te laten werken. EntityObject-gebaseerde entiteiten ondersteunen dit ook uit de doos, omdat ze worden gegenereerd als serialiseerbaar.
toegevoegd de auteur Ladislav Mrnka, de bron
@Merlyn: Real STE is entity gemaakt door Self Tracking Entities T4 Generator. Hier is mijn andere antwoord met verwijzingen naar referenties.
toegevoegd de auteur Ladislav Mrnka, de bron
@Merlyn: STEs zou moeten werken met WCF niet met eenvoudige MVC-lagen, maar ik ben echt geen fan van STEs - 1 , 2
toegevoegd de auteur Ladislav Mrnka, de bron
Ik heb het mis, maar ik denk dat dit begint met het ophalen van gegevens uit de database in plaats van gegevens te beperken tot datgene dat u expliciet hebt opgevraagd, omdat het alle navigatie-eigenschappen op een onbeperkte manier zal volgen. U krijgt de hele objectgrafiek, of u het nu leuk vindt of niet.
toegevoegd de auteur Merlyn Morgan-Graham, de bron
Wat bedoel je met "echt"? Zoals in, "echte mannen gebruiken die functie niet", of dat het aantoonbaar een waardeloze/schadelijke functie is? Of iets anders? Kun je daar een referentie voor opgeven? Ik daag je niet uit, ik ben hier om te leren :)
toegevoegd de auteur Merlyn Morgan-Graham, de bron
Tot nu toe heb ik dit probleem opgelost door geen entiteiten buiten de laag die zich bezighouden met DB-bewerkingen bloot te stellen en klassen op te blazen die minder gegevens blootstellen aan lagen van een hoger niveau (bijvoorbeeld door "weergavemodellen" door te geven aan MVC-weergaven). Het lijkt mij dat het serialiseren van een entiteit "het verkeerd doen" is. Heb je een andere mening?
toegevoegd de auteur Merlyn Morgan-Graham, de bron
een code die entiteiten klokt met behulp van DataContract serialisatie/deserialisatie: naspinski .be/na/Klonen-een-entiteit in-LINQ to Entities.asp & zwnj; x
toegevoegd de auteur surfen, de bron
Ik wil de kloon volhouden en niet alleen in het geheugen kopiëren
toegevoegd de auteur user440916, de bron

Als u 'kloon' zegt, wilt u dan een nieuwe entiteit maken die persistent is of gewoon een andere 'voorbijgaande' entiteit maken die een in-memory-kopie van dezelfde entiteit is?

Als u een in-memory-kopie wilt maken, kunt u altijd een nieuw exemplaar van de entiteitklasse maken en de velden kopiëren. Wijzigingen erin worden niet bijgehouden, omdat u de context er niet over hebt verteld.

var newInstance = new SomeEntity() { SomeProperty = oldInstance.SomeProperty };

Als u een nieuwe entiteit wilt maken die persistent is, voert u gewoon de normale bewerkingen uit die u zou uitvoeren om een ​​nieuwe record in te voegen. bijv .:

context.SomeEntities.Add(newInstance);

U kunt niet logisch een volledige kopie maken van wijzigingen, maar verwijst naar dezelfde instantie. Welke versie van het object zou je nemen?

0
toegevoegd
@ user440916: Kijk dan naar het tweede stukje code dat ik heb verstrekt, waar het de in-memory-kopie blijft behouden als een ander gegeven in de database.
toegevoegd de auteur Merlyn Morgan-Graham, de bron
Ik wil de diepe kloon volhouden en niet alleen in het geheugen kopiëren
toegevoegd de auteur user440916, de bron