c# OAuth 2.0库-如何实现领域模型
本文关键字：实现 领域模型 何实现 OAuth | 更新日期: 2023-09-27 17:50:13
OAuth 2.0规范正变得越来越稳定(http://tools.ietf.org/html/draft-ietf-oauth-v2)，我将为一个内部项目实现c# OAuth 2.0库。我想听听关于如何为图书馆实现一个明确的领域的意见。主要的关注点是:
- 如何命名类，是否应该将规范中描述具体概念的每个或大多数关键字制作成单独的类?
- 如何命名名称空间，是否应该将规范中讨论的每个主要主题都纳入单独的名称空间(身份验证、服务器、客户端、安全性等)
- 服务器和客户端资源应该如何建模(作为类中的属性，还是作为内部类)
- 还有更多的我将在他们出现时列出…
任何有根据规范(如众多的IETF规范)创建库的实际经验的人都会有很大的帮助。指出具有优秀规范实现的库也是非常有帮助的，这可以作为一个指南。
编辑:检查了DotNetOAuth CTP，但显然他们没有提供一个干净的模型作为灵感。
你可能选对了。一般来说，类和属性的名称应该基本遵循规范，并且应该在XML文档中包含指向规范的链接。通过匹配名称，熟悉标准的人可以更容易地理解代码在做什么。
我强烈建议在整个项目中包含单元测试。这不仅可以帮助您维护每个构建的完整性，而且还可以暴露出可用性不足的区域。例如，如果您发现自己不得不使用一大堆复杂的类和方法来请求对某些东西的身份验证，那么您就需要对其进行重构，以使库的使用者更容易使用它。
基本上，你的优先级应该按照这个顺序:
- 易于使用
- 匹配规格
除此之外，您可以根据个人喜好自由地实现它。您可能会注意到，有些领域有大量不同的库，以不同的方式完成相同的事情。这是一件好事，因为不同的人喜欢不同的东西。有些人想要一个反映规范的库，而另一些人则想要使用一个具有良好文档的库，而这些文档可能很难使用。其他人只是想要一些可以用几行代码工作的东西，并且不妨碍他们。这在很大程度上取决于你对这件事的看法。你不可能让所有人都满意，但你可以选择一条路，然后继续走下去。
也就是说，我建议不要使用过多的名称空间。对人们来说，做一个include MyOpenAuth比包含3个不同的命名空间要容易得多。在看起来合乎逻辑的地方使用它们，但一般来说，开放身份验证的概念可以被视为它自己的主题领域(在单一名称空间的保护伞下)。但是，这取决于你。