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

Question

OAuth 2.0规范变得越来越稳定（http://tools.ietf.org/html/draft-ietf-oauth-v2），我将为内部项目实现C＃OAuth 2.0库。 我想听听有关如何为图书馆实施明确领域的意见。 主要关注点是：

• 如何命名类，规范中描述具体概念的每个或大多数关键字都应归为单独的类吗？
• 如果命名规范中讨论的每个主要主题都应成为单独的命名空间（身份验证，服务器，客户端，安全性等），则如何命名命名空间
• 服务器和客户端资源应如何建模（作为类内部的属性还是内部类）
• 当它们出现时，我还会列出更多...

任何在创建超出规范的库（例如众多IETF规范）方面有实际经验的人都将提供巨大的帮助。 指出具有出色规范实现的库也将非常有帮助，可以作为指南。

编辑：签出了DotNetOAuth CTP，但显然他们没有提供一个受启发的干净模型。

Answer 1

您可能在正确的轨道上。 通常，类和属性的名称应在很大程度上遵循规范，并且您应在XML文档中包括指向规范的链接。 通过匹配名称，熟悉标准的人可以更轻松地了解代码的作用。

我强烈建议在整个项目中包含单元测试。 这不仅可以帮助您保持每个构建的完整性，而且还可以暴露出不应该使用的区域。 例如，如果您发现自己不得不使用复杂的类和方法来简单地请求对某些内容的身份验证，那么您需要对其进行重构，以使其对库的使用者更容易。

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

1. 工作代码
2. 易于使用
3. 文档
4. 符合规格

除此之外，您还可以根据自己的喜好自由实施它。 您可能会注意到，有些域包含大量不同的库，它们以不同的方式完成相同的任务。 这是一件好事，因为不同的人喜欢不同的事物。 有些人想要一个能够反映规范的库，而另一些人则希望使用带有良好文档的库，而这些文档可能很难使用。 其他人只是想要一些可以使用几行代码并且不妨碍自己的东西。 这很大程度上取决于您对此事的信念。 您不能全部取悦他们，而只是选择一个路径并运行它。

就是说，我建议不要过分命名空间。 人们进行include MyOpenAuth比包含3个不同的名称空间要容易得多。 在看起来合乎逻辑的地方使用它们，但通常，可以将开放身份验证的概念视为其自己的主题域（在单个名称空间的保护下）。 但是，这取决于您。