La règle CollectionPropertiesShouldBeReadOnly de FxCop est-elle incompatible avec la charpente à ressort?

Question

FxCop a le CollectionPropertiesShouldBeReadOnly rule qui se plaint si votre classe possède une sorte de propriété de collection que les clients peuvent définir. Au lieu de cela, il suggère de rendre la propriété en lecture seule et de fournir une méthode Clear() et des méthodes Add() ou AddRange() pour modifier le contenu de la collection. Je suis d'accord que cela rend l'interface plus propre et plus contrôlée, mais j'ai du mal à faire fonctionner cette interface avec le framework Spring. Si je veux configurer un objet avec une collection de collaborateurs, je dois exposer une propriété de collection pour y injecter les collaborateurs. J'ai regardé à travers the Spring documentation, et je ne peux pas voir aucun moyen de dire à Spring d'appeler la méthode AddRange(), ai-je oublié quelque chose?

Pour l'instant, je vais exclure l'avertissement avec une note que c'est nécessaire pour la configuration de printemps.

Mise à jour: depuis que je n'ai pas eu des amuse-gueules ici au cours des deux derniers mois, j'ai posté la même question sur le FxCop forum.

Answer 1

Si la propriété de collection n'a qu'un getter exposé, nous supposerons que les modèles recommandés par FxCop que vous utilisez sont utilisés et ajoutés à la collection. Le premier modèle est également pris en charge.

Pour les collections génériques, cela ne fonctionne que si la propriété exposée est de type IList. Nous avons un JIRA issue pour la prochaine version pour résoudre ce problème. BTW, c'est un modèle très commun dans les bibliothèques de classe de base (comme vous le savez probablement ...) où nous avons d'abord rencontré le besoin de supporter ce style dans .NET 1.1 (qui ne souffre pas de la limitation listée ci-dessus) .

Cheers, Mark

Answer 2

Le problème est-il aussi grave que vous le pensez? Je crois comprendre que FxCop se plaindra si vous avez une lecture/écriture des biens comme ceci:

public List<Foo> Items { get; set; } 

... parce que les utilisateurs de votre classe seraient alors en mesure de le faire:

myInstance.Items = new List<Foo>(); 

Évidemment, vous ne veulent pas que les utilisateurs de votre classe réattribuent complètement la liste. FxCop recommande donc ce modèle:

private List<Foo> _items = new List<Foo>(); 
public List<Foo> Items { get { return _items; } } 

Alors maintenant, les utilisateurs de votre classe ne peuvent ajouter et supprimer des éléments de votre liste, plutôt que de l'écraser avec une nouvelle instance de la liste.

Comment Spring.NET implémente-t-il ses propriétés de collection? Sont-ils vraiment lire/écrire comme mon premier exemple? Si c'est le cas, il serait intéressant de voir leurs cas d'utilisation pour un tel modèle, car cela ne semble pas correct.