La validation doit être capturée séparément des getters ou des setters dans une méthode de validation. Ainsi, si la validation doit être réutilisée sur plusieurs composants, elle est disponible.

Lorsque le setter est appelé, un tel service de validation doit être utilisé pour nettoyer l'entrée dans l'objet. De cette façon, vous savez que toutes les informations stockées dans un objet sont valides à tout moment.

Vous n'avez besoin d'aucun type de validation pour le getter, car les informations sur l'objet sont déjà considérées comme valides.

N'enregistrez pas votre validation avant une mise à jour de la base de données !! Il vaut mieux échouer rapidement.

Dans la perspective d'avoir le code le plus maintenable, je pense que vous devriez faire autant de validation que possible dans le setter d'une propriété. De cette façon, vous ne mettrez pas en cache ou ne traiterez pas de données invalides.

Après tout, c'est à cela que servent les propriétés. Si tout ce que vous avez est un tas de propriétés comme...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

... ils pourraient aussi bien être des champs

Cela dépend.

Généralement, le code devrait échouer rapidement. Si la valeur peut être définie par plusieurs points dans le code et que vous ne validez qu'après avoir récupéré la valeur, le bogue semble se trouver dans le code qui effectue la mise à jour. Si les setters valident l'entrée, vous savez quel code essaie de définir des valeurs invalides.

@Terrapin, re :

Si vous n'avez qu'un tas de [simples public set/get] propriétés ... ils pourrait tout aussi bien être des champs

Les propriétés ont d'autres avantages par rapport aux champs. C'est un contrat plus explicite, ils sont sérialisés, ils peuvent être débogués plus tard, c'est un bon endroit pour l'extension par héritage. La syntaxe plus maladroite est une complexité accidentelle - .net 3.5 par exemple surmonte cela.

Une pratique courante (et imparfaite) consiste à commencer par des champs publics et à les transformer en propriétés plus tard, selon les besoins. Cela rompt votre contrat avec quiconque consomme votre classe, il est donc préférable de commencer par les propriétés.

J'essaie de ne jamais laisser mes objets entrer dans un état invalide, donc les setters auraient certainement une validation ainsi que toutes les méthodes qui changent d'état. De cette façon, je n'ai jamais à m'inquiéter que l'objet avec lequel je traite soit invalide. Si vous conservez vos méthodes comme limites de validation, vous n'aurez jamais à vous soucier des frameworks de validation et des appels de méthode IsValid() dispersés partout.