Utilisation du setter d'objet pour déclencher des mises à jour de données, meilleures pratiques

Question

J'ai un objet qui est instancié dans une méthode linq to sql. Lorsque les champs d'objets sont assignés, je veux vérifier un champ de date et s'il s'agit d'une ancienne date, récupérer les données d'une autre table et effectuer des calculs avant de continuer à assigner cet objet.
Y a-t-il quelque chose de mal à déclencher un tel événement à travers le setter de propriété Ou devrais-je vérifier indépendamment la date à travers un service et faire les changements si nécessaire à un moment donné awewewards?

Answer 1

La moitié du point d'utiliser des setters à la place des champs publics, par exemple, est de pouvoir déclencher des événements associés à la définition de certaines données.

Mot-clé: associé. Si vous utilisez simplement le setter comme un temps "pratique" pour faire autre chose parce que cela fonctionne, vous le faites mal. Si la définition de cette valeur nécessite d'autres travaux, utilisez le setter pour ce faire.

Answer 2

Il n'y a rien de mal à faire de la logique à l'intérieur de vos setters, mais vous devez faire attention à la quantité de logique que vous mettez dans vos setters. L'un des problèmes fondamentaux des setters est que, comme ils agissent comme des attributs, mais qu'ils ont du code de support, il est facile d'oublier qu'il y a potentiellement des actions non-triviales qui se déroulent dans les coulisses.

Ce genre de chose peut causer des problèmes si vous avez des accesseurs qui utilisent des accesseurs qui utilisent des accesseurs; vous pouvez rapidement vous retrouver avec des problèmes de performance inattendus. Généralement, c'est une bonne idée de garder les actions des setters (ou getters, d'ailleurs) à un ensemble d'actions relativement petit. Par exemple, la validation peut fonctionner parfaitement dans un setter, mais je déconseille généralement de faire des validations sur des ressources externes, à cause de deux choses: premièrement, les retards de ressources peuvent causer des problèmes avec la vitesse d'accès attendue; les accès peuvent détruire votre performance.

Généralement, la règle est la suivante: gardez les choses simples. Ce n'est pas déraisonnable de faire des choses compliquées dans un setter, mais si vous le faites, il est vraiment important de comprendre les conséquences de toutes les actions que vous causerez, et il est extrêmement important de documenter ce qu'il fait extrêmement bien, donc le prochain gars (ou une fille) pour utiliser le code n'essaie pas seulement d'utiliser naïvement l'accesseur et finit par causer des problèmes de contention de ressources massives de façon inattendue.