C# OAuth 2.0 Library - How to Implement the Domain Model

OAuth 2.0 specs are getting more and more stable (http://tools.ietf.org/html/draft-ietf-oauth-v2) and I will be implementing C# OAuth 2.0 library for an internal project. I would like to hear opinions on how to implement a clear domain for the library. Major points of concern would be:

• How to name the classes, should every or most keywords in the specs describing concrete concepts be made into separate classes?
• How to name the namespaces, should every major topic discussed in the specification be made into a separate namespace (authentication, server, client, security, etc.)
• How should the server and client resources be modeled (as properties inside classes, or as inner classes)
• And many more I'll be listing as they come up...

Anybody with real experience in 开发者_如何学Ccreating libs out of specifications (like the numerous IETF specs) would be of monumental help. It would also be very helpful to point out libs with excellent spec implementations, which can act as a guide.

Edit: Checked out DotNetOAuth CTP but obviously they don't provide a clean model as to be inspired of.

You are probably on the right track. In general, names for classes and attributes should largely follow the spec, and you should include links to the specification within the XML documentation. By matching the names, a person familiar with the standard can more easily understand what the code is doing.

I would heavily recommend including unit tests for the complete project. Not only will this help you maintain the integrity of each build, but they will expose areas that are not as usable as they should be. For example, if you find yourself having to use a convoluted mess of classes and methods to simply request authentication for something, then you need to refactor it to be easier on the consumer of the library.

Basically, your priorities should be in this order:

1. Working code
2. Easy to Use
3. Documentation
4. Matching the Specification

Other than this, you have freedom to implement it to your personal preference. You may notice that there are some domains that have tons of different libraries that accomplish the same thing in different ways. This is a good thing, because different people like different things. Some people will want a library that mirrors a specification, while others will want to use one with good documentation that might be difficult to use. Others just want something that will work with a few lines of code and stay out of their way. It largely depends on your beliefs on the matter. You can't please them all, but just choose a path and run with it.

That said, I would recommend against excessive namespacing. It's much easier for people to do an include MyOpenAuth rather than include 3 different namespaces. Use them where it seems logical, but in general, the concept of Open Authentication can be considered it's own subject domain (under the umbrella of a single namespace). But, it's up to you.