C# OAuth 2.0 库 - 如何实现域模型
OAuth 2.0 规范变得越来越稳定 (http://tools.ietf.org/html/draft-ietf-oauth-v2)，我将为内部项目实现 C# OAuth 2.0 库。我想听听有关如何为图书馆实施清晰领域的意见。主要关注点是：
- 如何命名类，规范中描述具体概念的每个或大多数关键字是否应该分成单独的类？
- 如何命名命名空间，是否应将规范中讨论的每个主要主题制作为单独的命名空间（身份验证、服务器、客户端、安全性等）。
- 服务器和客户端资源应如何建模（作为类内的属性，或作为内部属性）类）
- 以及更多我将在出现时列出...
任何具有根据规范（如众多 IETF 规范）创建库的实际经验的人都将提供巨大的帮助。指出具有出色规范实现的库也非常有帮助，它可以作为指南。
编辑：查看了 DotNetOAuth CTP，但显然他们没有提供一个干净的模型来激发灵感。
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 creating 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能走在正确的轨道上。一般来说，类和属性的名称应在很大程度上遵循规范，并且应在 XML 文档中包含指向规范的链接。通过匹配名称，熟悉标准的人可以更容易地理解代码的用途。
我强烈建议为整个项目添加单元测试。这不仅可以帮助您保持每个构建的完整性，而且还会暴露出那些不那么可用的区域。例如，如果您发现自己必须使用复杂的类和方法来简单地请求对某些内容进行身份验证，那么您需要对其进行重构，以便对库的使用者来说更容易。
基本上，您的优先级应该按以下顺序排列：
除此之外，您可以根据个人喜好自由地实现它。您可能会注意到，有些领域拥有大量不同的库，它们以不同的方式完成相同的事情。这是一件好事，因为不同的人喜欢不同的东西。有些人想要一个反映规范的库，而另一些人则想要使用一个具有良好文档但可能难以使用的库。其他人只是想要一些可以用几行代码工作并且不妨碍他们的东西。这很大程度上取决于您对此事的信念。你不可能让所有人都满意，但只要选择一条路并走下去即可。
也就是说，我建议不要使用过多的命名空间。对于人们来说，
include MyOpenAuth比包含 3 个不同的命名空间要容易得多。在看起来合乎逻辑的地方使用它们，但一般来说，开放身份验证的概念可以被视为它自己的主题域（在单个命名空间的保护下）。但是，这取决于你。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:
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 MyOpenAuthrather 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.