Relation beaucoup à beaucoup de l'API fluide EF6

Pouvez-vous me donner une solution?

Si votre table de liaison dispose de colonnes supplémentaires, vous devez le modeler en tant qu'entité, et la logique de fin de la navigation doit être explicite. EF ne fera rien de cela pour vous.

Je ne veux pas en faire une entité car les 2 champs supplémentaires sont techniques (à des fins de journalisation) non fonctionnels. Ma requête ne doit pas être au courant de leur existence.

Je me demandais si je ne peux pas utiliser la fonction MapToprocédraine () mais je ne sais pas comment le faire ???

Les tables de jointure et EF

ef automatisent certaines choses pour vous. Pour cela, il utilise la convention-sur-configuration. Si vous vous en tenez à la convention, vous pouvez ignorer une grande quantité de configuration commune. P>

Par exemple, si votre entité a une propriété nommée ID code>, EF suppose intrinsèquement que cela est le pk. p>

De même, si deux types d'entités ont des accessoires NAV qui se réfèrent (et un seul lien direct entre les deux entités existe), puis ef supposera automatiquement que ces accessoires de navigation sont les deux côtés à un seul relation beaucoup à plusieurs. EF effectuera une table de jointure dans la base de données, mais cela vous cachera cela et vous permettra de vous cacher les deux types d'entité elles-mêmes. P>

Pour des raisons internes, la table de jointure a un format spécifique comprenant 4 champs - ID de gauche (FK) - ID de droite (FK) - StartDate (DateTime) - Enddate (DateTime) P> blockQuote>

Votre table de jointure n'est plus conforme à ce que le contenu d'une table de jointure EF classique et automatiquement générée est. Vous vous attendez à un niveau de configurabilité personnalisé que EF ne peut pas fournir sur la convention aveugle, ce qui signifie que vous devez configurer explicitement cela. P>

Deuxièmement, le fait que vous ayez ces colonnes supplémentaires implique que vous souhaitez utiliser cette Données à un moment donné (probablement pour montrer les relations historiques entre deux entités. Par conséquent, il n'a pas de sens à compter sur les tables de jointure automatiques de EF comme la table de jointure et le contenu informatique serait caché à partir de l'application / développeur. P>

Il est possible que la deuxième considération soit invalide pour vous, si vous n'avez pas besoin de l'application pour récupérer les entrées finies. Mais le point général est toujours debout. EM> P>

La solution ici est de faire enregistrer la jointure une entité explicite de ses propres. En substance, vous ne faites pas face à plusieurs à plusieurs ici, vous avez affaire à une entité spécifique (l'élément de jointure) avec deux De nombreuses relations (une pour chacun des deux types d'entités). P>

Cela vous permet d'obtenir exactement ce que vous voulez. Votre attente de ce que EF peut automatiser pour vous simplement ne s'applique simplement pas dans ce cas. P>

---

Soft Suppr H2>

La suppression d'un lien est en fait dans le réglage de la fin de la fin, comme non NULL, mais je ne sais pas maintenant comment le configurer dans EF6. P> BlockQuote>

En général, il est connu sous le nom de comportement "Soft Suppr", bien que peut-être légèrement différemment ici. Dans un motif de suppression doux régulier, lorsqu'une entrée est supprimée, la base de données conserve secrètement l'entrée, mais l'application ne sait pas cela et ne voit pas l'entrée à nouveau. P>

il n'est pas clair si vous l'intention des entrées finies de se présenter toujours dans l'application, par exemple l'histoire relationnelle. Si ce n'est pas le cas, votre situation est exactement strong> Soft Suppr comportement. Em> p>

Ce n'est pas quelque chose que vous configurez sur le niveau de modèle, mais plutôt quelque chose que vous Remplacez le comportement code> SAVECHANGES de votre base de données. Un exemple simple de la manière dont j'ai implémenter une suppression douce: p> xxx pré>

ceci vous permet d'éviter les suppressions aux entités souhaitées que celles-ci s'appliquent à, qui est le moyen le plus sûr d'implémenter Un doux Supprimer car cela sert de capture pour les suppressions de base de données provenant du consommateur utilise ce contexte de base de données. p>

La solution à votre question est à peu près la même chose. En supposant que vous ayez nommé votre implantation entité (voir chapitre précédent) JOINENTITY CODE>: P>

public override int SaveChanges()
{
    var entries = ChangeTracker.Entries<JoinEntity>().ToList();

    // Filter the entries that are being deleted
    foreach (var entry in entries.Where(entry.State == EntityState.Deleted))
    {
        // Change the entry so it instead updates the entry and does not delete it
        entry.Entity.Ended = DateTime.Now;
        entry.State = EntityState.Modified;
    }

    return base.SaveChanges();
}