根据角色为网站实现不同视图的最佳方法是什么？
在 ASP.NET 中，执行以下操作的最佳方法是什么：
- 根据您的权限显示某些控件？
- 对于 gridview 控件，如何根据您的角色显示某些列？
我正在考虑第二点，让数据来自数据库中特定于角色的视图。
In ASP.NET what's the best way to do the following:
- Show certain controls based on your rights?
- For a gridview control, how do you show certain columns based on your role?
I'm thinking for number 2, have the data come from a role specific view on the database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议不要实际使用角色来隐藏/显示某些控件，而是建议为每个角色设置另一层权限，并根据这些权限进行显示/隐藏。
这样您就可以重新定义角色拥有的权限，而不必更改代码。
此外，这还允许您将来创建新角色，并且只需为该角色分配一组权限即可。
至于控件，是的...我只需根据 user.IsInRole("permissionname") 值设置控件上的 Visible 属性。
对于网格，我会做同样的事情...将列的可见性设置为 IsInRole 布尔值。
我会以非常细粒度的方式创建您的权限..例如
Instead of actually using roles to hide/show certain controls, I would suggest having another layer of permissions for each role and show/hide based on those instead.
That way you can redefine what permissions a role has and won't have to change your code.
Also, this allows you to make new roles in the future and just assign a set of permissions to the role.
As for controls, yes... I would just set the Visible property on the control based on the user.IsInRole("permissionname") value.
For grids I would do the same... set the Visibility of the columns to the IsInRole boolean value.
I would make create your permissions in a very granular nature.. such as
如果您要采用基于角色的路线，ASP.NET（自版本 2.0 起）提供了各种可用的成员资格控件，这在这种情况下可能会有所帮助。 假设（这很可能是一个错误的假设）您正在使用内置会员资格提供程序，您实际上可以使用
LoginView控件来处理#1。它的工作方式是，
LoginView可以使用RoleGroups及其关联的ContentTemplates根据角色为用户自定义视图。 这与内置会员提供商无缝协作； 我相信，如果您基于微软的技术构建自己的会员服务提供商，它也会起作用。 （我还没有完成后一步。）可以想象，您可以将其用于#2，但最终会产生重复的代码和工作，这不是我个人的偏好。 我认为您选择使用特定于角色的 SQL 视图来驱动该表可能比此选项更好。 （当然，还有其他选项，可能会更好。）
我会赞同 Elijah Manor 关于使用权限而不是角色的建议。 一般来说，这也是我的偏好。 （我很惊讶地发现会员提供商的技术没有达到那个水平。）但是，在任何以权限为中心的场景中，您基本上都必须自己滚动所有内容。 （我已经这样做了，虽然它非常灵活，但保护任何给定页面的代码可能会变得很麻烦。）
编辑：我道歉； 我的意思是包含 LoginView 控件的链接。 DotNetJunkies 有一个教程。
If you're going the role-based route, ASP.NET (since version 2.0) has had a variety of membership controls available which might help in this scenario. Assuming (and this could well be a faulty assumption) that you're using the in-box membership provider, you can actually use the
LoginViewcontrol to get #1 handled.The way it works is that the
LoginViewcan useRoleGroupsand their associatedContentTemplatesto customize the view for the user based on role. This works seamlessly with the in-box membership provider; I believe if you build your own membership provider based on Microsoft's technology it will also work. (I haven't done this latter step.)Conceivably, you could use it for #2, but it'd wind up with duplicated code and effort, which isn't my personal preference. I think your choice of using role-specific SQL views to drive that table may be better than this option. (There are other options as well, of course, which may be better.)
I will second Elijah Manor's recommendation of using permissions instead of roles. Generally, that's my preference as well. (And I was surprised to discover that the membership provider technology didn't go to that level.) In any permission-centric scenario, though, you will essentially have to roll everything yourself. (I've done this, and while it's very flexible, the code to secure any given page can get hairy.)
EDIT: I apologize; I meant to include a link for the LoginView control. DotNetJunkies has a tutorial on it.