Question

Microsoft a récemment mis un communiqué de leur contrats cadre sur DevLabs avec une licence commerciale. Nous sommes intéressés à les utiliser dans notre projet (la plupart du temps C #, certains C ++ / CLI) pour remplacer progressivement tout le code de validation personnalisé, mais je suis désireux de connaître l'expérience d'autres personnes ont eu avec elle avant de nous engager à lui, en particulier:

  • Pensez-vous que le cadre est suffisamment mûre pour que des projets commerciaux importants et complexes?

  • Quels problèmes avez-vous courir dans tout l'utiliser?

  • Quels avantages avez-vous de lui?

  • Est-il actuellement plus de douleur que cela vaut la peine?

Je me rends compte que cela est une question quelque peu subjective car il requiert l'avis, mais étant donné que ce cadre est une partie très importante de .NET 4.0 et (potentiellement) changer la façon dont nous avons tous le code de validation d'écriture, j'espère que cette question sera laissée ouverte pour acquérir de l'expérience sur le sujet pour me aider à prendre une décision à une question spécifique, responsable:

  

Doit-on commencer à utiliser le mois prochain?

Notez que nous ne livrons pas une API de code, seul un service Web un, donc pour la majorité des ne sont pas une préoccupation de code casser la compatibilité en termes de type d'exception jetée. Cependant, comme je l'espère plus de gens que me bénéficieront de ce poste et de ses réponses, aucun détail dans ce domaine est plus que bienvenue.

Était-ce utile?

La solution 2

Je joue avec le code contracte un peu plus sur moi-même un petit projet autonome modérément complexe, qui doit hériter de certaines classes BCL et utiliser d'autres.

Les contrats chose semble grande quand vous travaillez dans un environnement complètement isolé avec juste vos propres types de code et primitifs, mais dès que vous commencez à utiliser les classes BCL (qui, jusqu'à .NET 4.0 n'ont pas leurs propres contrats) le vérificateur ne peut pas vérifier si elles enfreindre requires / / se assure invariants et donc vous obtenez beaucoup d'avertissements sur les contraintes potentiellement insatisfaits.

Par contre, il trouve des contraintes non valides ou potentiellement insatisfaits qui pourraient être des bugs réels. Mais il est très difficile de trouver ces car il y a tellement de bruit qu'il est difficile de savoir quels sont ceux que vous pouvez corriger. Il est possible de supprimer les avertissements des classes BCL en utilisant le mécanisme suppose, mais cela est quelque peu autodestructrice que ces classes ont des contrats à l'avenir et les hypothèses diminuera leur valeur.

Donc, mon sentiment est que pour l'instant, parce que dans 3.5, nous essayons de construire un cadre que le vérificateur ne comprend pas suffisamment, que c'est probablement la peine d'attendre 4.0.

Autres conseils

La dernière réponse mature à c'était en 2009 et .NET 4 est sorti. Je figure que nous sommes en raison d'une mise à jour:

Code des marchés pourrait bien être assez mature pour vos versions de débogage.

Je sais que cela est en quelque sorte une mise à niveau « Inoffensif » à « Mostly Harmless ».

Le code des marchés page d'accueil liens vers la documentation assez complète au format PDF. La documentation décrit les lignes directrices d'utilisation dans la section 5. En résumé, vous pouvez choisir comment vous vous sentez courageux sur les outils du contrat réécrivant votre IL dans votre communiqué builds.

Nous utilisons le mode « ne pas réécrire ma libération IL ».

Jusqu'à présent, je suis plus profiter de cet avantage inattendu: il y a moins de code, donc moins de code pour tester . Toutes vos clauses de garde fondent.

if(arg != null) { 
    throw new ArgumentNullException("arg"); 
}
// Blank line here insisted upon by StyleCop

devient:

Contract.Requires(arg != null);

Vos fonctions sont plus courtes. Votre intention est claire. , vous n'avez plus d'écrire un test nommé ArgumentShouldNotBeNull juste pour atteindre une couverture de 100%.

Jusqu'à présent, j'ai rencontré deux problèmes:

  • J'ai eu un test unitaire qui reposait sur un échec du contrat pour réussir. Vous pourriez arguer de l'existence du test était une erreur, mais je voulais documenter cette interdiction particulière sous la forme d'un test. Le test a échoué sur mon serveur de build parce que je n'ai pas les outils mis en place. Solution:. Installer les outils

  • Nous utilisons deux outils qui réécrivent IL: code des marchés et PostSharp . Ils ne se entendaient pas trop bien. 2.0.8.1283 de PostSharp résolu le problème. Je prudemment évaluer comment any deux outils IL-ré-écriture se entendent, cependant.

Jusqu'à présent, les avantages sont les risques l'emportent.

Répondre aux préoccupations hors jour soulevées dans d'autres réponses:

  • Code de la documentation de contrats est assez complet, mais malheureusement au format PDF.
  • Il y a au moins un Code Forum contrat hébergé par Microsoft.
  • Code des marchés Standard Edition est gratuit si vous avez une licence de VS2010.
  • .NET 4 est sorti. J'ai couru dans les contrats de Microsoft lors de l'implémentation des interfaces de collecte génériques.

A en juger par le titre ce fil je dirais que ce n'est pas assez mature pour utiliser pour un projet de niveau de l'entreprise. Je ne l'ai pas utilisé moi-même, mais les gens sont en cours d'exécution encore dans des bugs qui apporteraient votre projet de contrat critiques à l'arrêt. Il semble comme un cadre vraiment super et les vidéos par exemple qu'ils ont fourni ont été excitant, mais je voudrais attendre:

  • Existence d'un forum communautaire. Vous allez vouloir être en mesure de discuter des problèmes inévitables vous rencontrez avec d'autres développeurs, et que vous voulez savoir qu'il ya une base décemment forte des développeurs sur là pour discuter de solutions avec.
  • Un lancement réussi du projet pilote. En général, lorsque Microsoft Research publie quelque chose qu'ils pensent est assez mature pour être utilisé dans un projet commercial, ils travailleront avec une organisation à ce pilote, puis relâchez ce projet open source comme une preuve de concept et le procès par le feu de toutes les principales caractéristiques. Cela donnerait beaucoup de confiance que la plupart des scénarios de contrats communs sont couverts et le travail.
  • documentation plus complète. Purement et simplement, à un moment donné, vous allez vouloir faire quelque chose avec les contrats que vous ne pouvez pas faire encore à l'aide de contrats Microsoft Code. Vous voulez être en mesure de rapidement et clairement raison que votre scénario est pas encore pris en charge. La documentation actuelle va vous garder deviner et d'essayer différentes choses, mais, à mon avis, ce qui se traduira par une beaucoup de temps perdu.

Il est pas assez mature.

Il sera dès que Microsoft libère les éditions abordables de VS, mais sans l'analyse de code statique, il est pas du tout utilisable.

Les éditions de VS, qui l'ont, sont si coûteux que seulement incroyablement une poignée de personnes ne sera jamais en mesure de le permettre.

Il est dommage Microsoft tué cette idée étonnante avec leur politique de prix. I Code souhaite contrats deviendraient traditionnels, mais ils ne.

epic fail.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top