c# français - Entity Framework.Remove()par rapport à.DeleteObject()





tutorial pdf (3)


Si vous voulez vraiment utiliser Deleted, vous devrez rendre vos clés étrangères nulles, mais vous finirez avec des enregistrements orphelins (ce qui est l'une des principales raisons pour lesquelles vous ne devriez pas le faire en premier lieu). Il suffit donc d'utiliser Remove()

ObjectContext.DeleteObject (entité) marque l'entité comme Supprimé dans le contexte. (EntityState est supprimé par la suite.) Si vous appelez SaveChanges après, EF envoie une instruction SQL DELETE à la base de données. Si aucune contrainte référentielle dans la base de données n'est violée, l'entité sera supprimée, sinon une exception est levée.

EntityCollection.Remove (childEntity) marque la relation entre parent et childEntity comme Deleted. Si childEntity est lui-même supprimé de la base de données et que ce qui se passe exactement lorsque vous appelez SaveChanges dépend du type de relation entre les deux:

Une chose à noter est que le réglage .State = EntityState.Deleted ne déclenche pas automatiquement la modification détectée. ( archive )

Vous pouvez supprimer un élément d'une base de données en utilisant EF en utilisant les deux méthodes suivantes.

Le premier est sur EntityCollection et le second sur ObjectContext .

Quand devrait-on utiliser chacun d'eux?

L'un est-il préféré à l'autre?

Remove() renvoie un bool et DeleteObject() renvoie void .




Il n'est généralement pas correct de pouvoir " supprimer un élément d'une base de données " avec les deux méthodes. Pour être précis, c'est comme ça:

  • ObjectContext.DeleteObject(entity) marque l'entité comme Deleted dans le contexte. ( EntityState est Deleted suite.) Si vous appelez SaveChanges après, EF envoie une instruction SQL DELETE à la base de données. Si aucune contrainte référentielle dans la base de données n'est violée, l'entité sera supprimée, sinon une exception est levée.

  • EntityCollection.Remove(childEntity) marque la relation entre parent et childEntity comme Deleted . Si childEntity est lui-même supprimé de la base de données et que ce qui se passe exactement lorsque vous appelez SaveChanges dépend du type de relation entre les deux:

    • Si la relation est facultative , c'est-à-dire que la clé étrangère qui fait référence à l'enfant dans la base de données autorise les valeurs NULL , cet étranger sera défini sur null et si vous appelez SaveChanges cette valeur NULL pour childEntity sera écrite dans la base de données. c'est-à-dire que la relation entre les deux est supprimée). Cela se produit avec une instruction SQL UPDATE . Aucune instruction DELETE se produit.

    • Si la relation est requise (le FK n'autorise pas les valeurs NULL ) et que la relation n'identifie pas (ce qui signifie que la clé étrangère ne fait pas partie de la clé primaire (composite) de l'enfant), vous devez ajouter l'enfant à un autre parent ou vous devez supprimer explicitement l'enfant (avec DeleteObject alors). Si vous n'en faites aucune, une contrainte référentielle est violée et EF lancera une exception lorsque vous appellerez SaveChanges - l'infâme " La relation ne peut pas être modifiée car une ou plusieurs propriétés de clé étrangère est non nulle ". ou similaire.

    • Si la relation est identifiée (elle est nécessairement requise, car toute partie de la clé primaire ne peut pas être NULL ) EF indiquera également childEntity comme Deleted . Si vous appelez SaveChanges une instruction SQL DELETE sera envoyée à la base de données. Si aucune autre contrainte référentielle dans la base de données n'est violée, l'entité sera supprimée, sinon une exception est levée.

Je suis un peu confus à propos de la section Remarques sur la page MSDN que vous avez liée car elle indique: " Si la relation a une contrainte d'intégrité référentielle, l'appel de la méthode Remove sur un objet dépend marque la relation et l'objet dépendant pour la suppression. ". Cela me semble imprécis ou même erroné car les trois cas ci-dessus ont une « contrainte d'intégrité référentielle » mais seulement dans le dernier cas, l'enfant est effectivement supprimé. (À moins qu'ils ne signifient avec " objet dépendant " un objet qui participe à une relation d'identification qui serait cependant une terminologie inhabituelle.)




Le code ci-dessous a aidé mon objet à être actualisé avec de nouvelles valeurs de base de données. La commande Entry (object) .Reload () force l'objet à rappeler les valeurs de la base de données

GM_MEMBERS member = DatabaseObjectContext.GM_MEMBERS.FirstOrDefault(p => p.Username == username && p.ApplicationName == this.ApplicationName);
DatabaseObjectContext.Entry(member).Reload();




c# database entity-framework orm