J'ai commencé en créant des modèles comme celui-ci: et j'utilise cette ligne lorsque l'application démarre: une table Les projets appelés sont créés avec toutes les propriétés mentionnées ci-dessus en tant que colonnes ... c'est exactement ce que je voulais. Cependant, je n'ai plus besoin de peupler certaines valeurs par défaut lorsque je publie des SAVECONGES () sur DBContext. Lorsque je sauvegarder, j'ai besoin de mettre à jour les propriétés de modifié et modifié des propriétés avec les valeurs appropriées. Normalement, je ferais au moins les valeurs DateTime du côté de la base de données (un déclencheur ou une procédure stockée) mais cela est évidemment Pas une option ici puisque la base de données sera supprimée à tout moment, une classe change. Et comme je l'ai fait du code d'abord, je n'ai pas de concepteur modèle que je peux modifier les propriétés. Ce que je voudrais faire est d'ajouter une méthode dans la classe EditablesBase qui est appelée lorsque les SAVECHANGES () est exécuté, gardant ainsi toute la logique impliquée dans un seul endroit. Est-il possible de faire cela? Quelle est la meilleure façon d'atteindre mon objectif?
3 Réponses :
Eh bien, vous avez un contrôle complet sur le code de vos entités. J'imagine que vous voudriez probablement mettre en œuvre un motif d'IproperTychanged comme pour mettre à jour vos propriétés.
Pouvez-vous éventuellement développer cette réponse? Je sais que j'ai un contrôle total sur mes entités, mais je ne sais pas que j'ai un contrôle total sur la méthode Savechanges () dans DBContext. Où est le crochet dont j'ai besoin?
Je soulignais simplement que vous pourriez mettre en œuvre une ipropertychangned sur vos entités (semblable au WPF); AKA, lorsqu'une propriété change, vous mettez à jour vous-même la propriété MODIFIDEON à la place de SAVECHANGES INTÉRIEURES.
Je vois ce que tu veux dire maintenant. Cela semble potentiellement beaucoup de travail. Par exemple, si j'ai une douzaine de modèles qui héritent de EditBase et chacun de ceux-ci ont 20 ou 30 propriétés, je dois ajouter beaucoup de code pour quelque chose que je savoir sera toujours nécessaire quand le Editbase est héritée et les SAVECHANGES () sont appelées.
Supprimer Je ne sais que si générique SAVECHANGES dans votre dBContext : entrées Travaillera directement avec votre type de base parce qu'il n'est pas effectivement cartographié en tant qu'entité de base. Il existe également une version non générique afin que vous puissiez la réécrire à une requête de Linq plus complexe ou à tester chaque entrée d'entité d'entrée en boucle.
Cela semble être la réponse la plus correcte. Je ne suis pas vraiment ravi de le faire parce que cela semble trop haut, mais je ne vois aucune autre option.
Je l'ai utilisé pour la serviette uniquement. Mais quand je fais une modification, cette valeur est écrasée et réglée sur une chaîne null ou vide
Et si vous utilisez des propriétés auto-utilisées, aura-t-il le même effet?: DateTime public modifiedon {obtenir; ensemble; } = Datetime.now;
a pris en compte les deux options de La solution d'attribut par défaut semble une bonne.
Eh bien, cette solution fonctionne partiellement et c'est finalement ce que j'ai choisi de faire. C'est un peu maladroit cependant. Cela ne fonctionne pas lorsque des charges valorisées enregistrées et écrasent quel que soit le constructeur. Modifiedby est un bon exemple de cela. Je veux vraiment mettre cela seulement lorsque je sauvegarde.
Belle convention de dénomination! Je ne pouvais pas comprendre un moyen d'obtenir le type de données (date) sur les noms des champs de date.