C# OAuth 2.0库--如何实现域模型

Question

OAuth 2.0规范越来越稳定(http://tools.ietf.org/html/draft-ietf-oauth-v2)，我将为内部项目实现C# OAuth 2.0库。我想听听关于如何为图书馆实现一个明确的域的意见。令人关切的主要问题是：

• 如何命名类，是否应该将描述具体概念的规范中的每个或大多数关键字分别命名为不同的类？
• 如何命名名称空间，是否应该将规范中讨论的每个主要主题变成单独的命名空间(身份验证、服务器、客户端、安全性等)
• 如何建模服务器和客户端资源(作为类内的属性或内部类)
• ，以及在它们出现时，我将列出的更多内容.

F 210

任何在创建基于规范的库(比如众多IETF规范)方面有实际经验的人都会得到巨大的帮助。指出具有出色的规范实现的libs也是非常有帮助的，它可以作为指南。

编辑:签出的DotNetOAuth CTP，但很明显，他们没有提供一个干净的模型作为灵感的启发。

Answer 1

你可能在正确的轨道上。通常，类和属性的名称应该在很大程度上遵循规范，并且您应该在XML文档中包含到规范的链接。通过匹配这些名称，熟悉该标准的人可以更容易地理解代码所做的事情。

我强烈建议包括完整项目的单元测试。这不仅将帮助您维护每个构建的完整性，而且还将暴露那些不应该使用的区域。例如，如果您发现自己不得不使用复杂的类和方法来简单地请求某些东西的身份验证，那么您需要重构它，以便对库的使用者更容易。

基本上，您的优先级应该按照以下顺序排列：

• Documentation

• Matching

1. 工作代码
2. 易于使用的规范

除此之外，你还可以根据你的个人喜好来实现它。您可能会注意到，有些域拥有大量不同的库，它们以不同的方式完成了相同的任务。这是一件好事，因为不同的人喜欢不同的东西。有些人会想要一个反映规范的库，而另一些人则希望使用一个很好的文档，而这些文档可能很难使用。其他人只是想要的东西，将工作与几行代码，并避开他们的方式。这在很大程度上取决于你对这件事的信念。你不能让他们都满意，只要选择一条路就行了。

尽管如此，我建议不要过多地使用名称空间。对于人们来说，做include MyOpenAuth要容易得多，而不是包含3个不同的名称空间。在看起来合乎逻辑的地方使用它们，但是一般来说，开放身份验证的概念可以被认为是它自己的主题域(在单个名称空间的保护伞下)。但是，这取决于你。