直接致电提供商是否被认为是不好的做法？
我正在 .NET 成员资格框架中实现自定义 RoleProvider。现有的功能需要一些调整，所以我想实现我自己的公共函数，以围绕静态角色类进行调用。
而不是对象->角色 ->角色提供者 我会去对象-> RolesProvider
这会被视为不好的做法吗？当前数据库方案的唯一替代方案是完全省略 RoleProvider 的使用，并实现我自己的自定义授权系统。
编辑：为了澄清，我已经实现了一个自定义的 MembershipProvider，因此继续在 Membership 框架中工作的愿望非常高。
I'm implementing a Custom RoleProvider in the .NET Membership-framework. The existing functionally needs a little tweaking, so I want to implemenet my own Public Functions, to invoke around the static Roles-class.
Instead of Object -> Roles -> RolesProvider
I would go Object -> RolesProvider
Would this be considered bad practice? The only alternative with the current databasescheme is to ommit the use of RoleProvider totally, and implement my own custom system for authorization.
Edit: To clarify, I have already implemented a custom MembershipProvider, so the desire to keep working in the Membership-framework is pretty high.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
任何时候您规避框架的一部分或以非预期的方式对其进行自定义，都可能被视为不好的做法。 ASP.NET 成员资格提供程序框架的目的是通过
Roles类促进对当前提供程序的访问。“弯曲”框架以满足您的需求而不是按预期扩展框架的危险在于：.net 框架中可能还有其他区域、围绕角色成员资格功能的配置或工具做出了这种假设，并且它们更改后可能不再有意义，并导致参与您项目的其他人感到困惑。 ASP.NET 网站管理工具就是做出这一假设的工具的一个示例。如果有人在您进行更改后使用此工具，您的角色成员资格和网站可能会因此而损坏。
如果您决定采用这种方法，您应该仔细考虑要添加哪些功能，并最终问问自己这是否真的有必要。如果是这样，您最好实现完全自定义的东西，以避免混淆。
Any time you circumvent part of a framework or customize it in a way that was not intended it could be considered bad practice. It is the intention of the ASP.NET membership provider framework to facilitate access to the current provider through the
Rolesclass.The danger of 'bending' the framework to suit your needs instead of extending it as intended is this: there may be other areas in the .net framework, configuration or tools around the role membership functionality that make this assumption, and they may no longer make sense after your changes and cause confusion for others involved in your project. The ASP.NET Website Administration Tool is one example of a tool that makes this assumption. If someone were to use this tool after your changes, your role memberships and site could be potentially corrupted as a result.
If you decide to take this approach you should carefully consider what functionality you are adding and ultimately ask yourself it is really necessary. If it is, you may be better off implementing something completely custom instead to avoid confusion.