0

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

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

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

编辑：检查了 DotNetOAuth CTP，但显然他们没有提供一个干净的模型来激发灵感。

4

1 回答 1

4

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

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

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

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

除此之外，您可以根据个人喜好自由实施。您可能会注意到，有些领域拥有大量不同的库，它们以不同的方式完成相同的事情。这是一件好事，因为不同的人喜欢不同的东西。有些人会想要一个反映规范的库，而另一些人会想要使用一个可能难以使用的具有良好文档的库。其他人只是想要一些可以使用几行代码并且不会妨碍他们的东西。这在很大程度上取决于您对此事的信念。你不能取悦他们所有人，而只是选择一条路并顺其自然。

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

于 2011-04-14T03:07:45.330 回答