C# OAuth 2.0 Library - Comment mettre en œuvre le modèle de domaine

Question

OAuth 2.0 spécifications sont de plus en plus stable (http://tools.ietf.org/html/draft-ietf-oauth-v2) et j'implantera C# Bibliothèque OAuth 2.0 pour un projet interne. Je voudrais entendre des opinions sur la façon de mettre en œuvre un domaine clair pour la bibliothèque. Les principaux points d'intérêt seraient:

• Comment nommer les classes, doivent tous ou la plupart des mots-clés dans les spécifications décrivant les concepts concrets soient pris en classes séparées? Comment nommer les espaces de noms, si tous les sujets principaux abordés dans la spécification doivent être placés dans un espace de noms distinct (authentification, serveur, client, sécurité, etc.)
• Comment les ressources serveur et client doivent-elles être modélisées (comme propriétés des classes à l'intérieur, ou en tant que classes internes)
• Et beaucoup d'autres je serai COTATION comme ils viennent ...

Toute personne ayant une réelle expérience dans la création libs de spécifications (comme les nombreuses spécifications IETF) seraient être d'une aide monumentale. Il serait également très utile de signaler les bibliothèques avec d'excellentes implémentations de spécifications, qui peuvent servir de guide.

Edit: Vérifié sur DotNetOAuth CTP, mais il est évident qu'ils ne fournissent pas un modèle propre à être inspiré de.

Answer 1

Vous êtes probablement sur la bonne voie. En général, les noms des classes et des attributs doivent suivre largement la spécification, et vous devez inclure des liens vers la spécification dans la documentation XML. En faisant correspondre les noms, une personne familière avec la norme peut plus facilement comprendre ce que fait le code.

Je recommande fortement d'inclure des tests unitaires pour le projet complet. Non seulement cela vous aidera à maintenir l'intégrité de chaque build, mais ils exposeront des zones qui ne sont pas aussi utilisables qu'elles devraient l'être. Par exemple, si vous devez utiliser un mélange compliqué de classes et de méthodes pour demander simplement l'authentification de quelque chose, vous devez le refactoriser pour qu'il soit plus facile pour le consommateur de la bibliothèque.

Fondamentalement, vos priorités devraient être dans cet ordre:

1. Code de travail
2. Facile à utiliser
3. Documentation
4. Adaptation de la spécification

Autre que cela, vous avez la liberté de l'appliquer à votre préférence personnelle. Vous remarquerez peut-être que certains domaines ont des tonnes de bibliothèques différentes qui accomplissent la même chose de différentes manières. C'est une bonne chose, parce que différentes personnes aiment différentes choses. Certaines personnes voudront une bibliothèque qui reflète une spécification, tandis que d'autres voudront en utiliser une avec une bonne documentation qui pourrait être difficile à utiliser. D'autres veulent juste quelque chose qui va fonctionner avec quelques lignes de code et rester hors de leur chemin. Cela dépend en grande partie de vos croyances en la matière. Vous ne pouvez pas tous les satisfaire, mais choisissez simplement un chemin et courez avec.

Cela dit, je recommande de ne pas utiliser un espace de noms excessif. Il est beaucoup plus facile pour les gens de faire un include MyOpenAuth plutôt que d'inclure 3 espaces de noms différents. Utilisez-les là où cela semble logique, mais en général, le concept d'authentification ouverte peut être considéré comme son propre domaine (sous l'égide d'un seul espace de noms). Mais c'est à toi de voir.