C＃OAuth 2.0ライブラリ - ドメインモデルを実装する方法

Question

OAuth 2.0の仕様はますます安定しており（http://tools.ietf.org/html/draft-ietf-oauth-v2）、私はC＃内部プロジェクト用のOAuth 2.0ライブラリ。私は図書館の明確なドメインをどのように実装するかについての意見を聞きたいと思います。主な留意点は、

• 具体的な概念を記述している仕様の中のすべてまたはほとんどのキーワードを別々のクラスにする必要がありますか？名前空間に名前を付ける方法
• は、明細書で論じられるすべての主要なトピックは、プロパティとして（別の名前空間（認証、サーバー、クライアント、セキュリティなど）
• サーバとクライアントのリソースをモデル化する必要がありますどのようになされるべきですクラスの内部、または内部クラスなど）
• そして、より多くの彼らが出てくるように私がリストされます...数々のIETF仕様のような規格外のlibsを作成する際に、実際の経験を持つ

誰も（）だろう記念碑的な助けを要する。ガイドとして機能することができる、優れた仕様の実装を持つlibsを指摘することも非常に役立ちます。

編集：DotNetOAuth CTPをチェックアウトしましたが、明らかに、彼らは霊感を受けたようなクリーンなモデルを提供していません。

Answer 1

あなたはおそらく正しい軌道にいるでしょう。一般的に、クラスと属性の名前は仕様に大きく準拠している必要があります。また、XMLドキュメントに仕様へのリンクを含める必要があります。名前を照合することで、標準に精通している人は、コードが何をしているのかをより簡単に理解することができます。

完全なプロジェクトの単体テストを含めることを強くお勧めします。これは、各ビルドの整合性を維持するのに役立つだけでなく、使用可能でないほどの領域を公開します。たとえば、何かの認証を要求するためにクラスやメソッドの混乱した混乱を使わなければならない場合は、ライブラリのコンシューマを簡単にするためにリファクタリングする必要があります。

基本的には、あなたの優先順位は、この順番でなければなりません：

1. の作業コード
2. 簡単仕様にあなたが持っているこれ以外

を、マッチング

ドキュメント

を使用しますそれをあなたの個人的な好みに適用する自由。あなたは、異なる方法で同じことを達成する異なるライブラリのトンを持ついくつかのドメインがあることに気付くかもしれません。これは良いことです。なぜなら、異なる人々は異なるものを好むからです。仕様を反映したライブラリが必要な人もいれば、使いにくいかもしれないドキュメントがあるものを使いたい人もいます。他の人は、数行のコードで作業し、途中にいないものを望んでいるだけです。主にあなたの信念に左右されます。あなたはそれらをすべて喜ばせることはできませんが、道を選んで走ってください。

しかし、私は過度の名前空間を使うことをお勧めします。人々が3つの異なる名前空間を含めるのではなく、include MyOpenAuthを実行する方がはるかに簡単です。論理的に見える場所で使用しますが、一般にオープン認証の概念は、（単一のネームスペースの傘下にある）それ自身のサブジェクトドメインと見なすことができます。しかし、それはあなた次第です。