Question

我有一个经典的3层ASP.Net 3.5 Web应用程序，其中包含显示业务对象并允许对其进行编辑的表单。表单上的控件对应于底层业务对象的属性。用户将具有读/写，只读或不能访问各种控件，具体取决于他/她的角色。非常传统的东西。

我的问题是：用于编码的面向对象最佳实践是什么？有没有比在测试中包装每个控件更优雅的用户角色并设置其Visible和Enabled属性？

由于

Answer 1

你会想要驱逐这些数据，相信我。你需要很多表才能做到这一点，但最终还是值得的。每次企业想要更改权限时，必须破解开放代码并编辑一堆if语句是一个杀手锏。

你需要一个主要高级类型的表，你可能已经拥有业务对象的东西。然后是每个状态的表格。然后是这些类的字段的表。然后是一个用户角色表（admin，guest等）。最后是一个权限表本身。此表将包含业务类，状态，字段，用户角色以及他们拥有的权限列。对于权限，我会使用一个字段并使用枚举：Hidden，ReadOnly，Editable和Required。必需表示可编辑。除隐藏之外的任何东西都暗示可见。最后在此表上放置一个Priority列，以控制在可能应用多个权限时使用哪个权限。

您可以使用类，状态，字段，角色和权限的各种组合填写此表。如果值为null，则它适用于所有可能的值。因此，您不需要万亿行来覆盖所有基础。例如，99％的时间，Guest用户是只读用户。因此，您可以在表中放置一个条目，仅指定Guest角色，其他所有内容都为null，并将其设置为Priority和high，并将权限设置为Read Only。现在对于所有类，所有状态，所有字段，如果用户是访客，他们将具有只读权限。

我在您的关注列表中添加了状态，因为根据我的经验，业务总是希望通过对象的状态来约束事物。因此，例如，用户可以在处于“草稿”状态时编辑项目的名称，但是一旦处于“已发布”状态，该名称就不再可编辑。这在我的经历中非常普遍。

你想把这张表带入内存并将其存储在应用程序的缓存中，因为除非你做一个全新的版本，否则不会经常更改，除非你做了一个全新的版本。

现在，我怀疑上述将满足您90％的需求。

必须在代码中处理的一个区域，除非您想要真正看中，否则用户的权限部分由值中的字段决定对象本身。所以说你有一个Project类，它有一个Project Manager类。现在，对于每个人来说，类的Percent Complete字段基本上是只读的，除了项目管理器。你打算如何处理？您需要提供一种方法，将特定的类实例合并到决策过程中。我在代码中这样做。

Answer 2

为了正常工作，我发现访问级别应按此递增顺序：无，查看，需要，编辑。

请注意，由于EDIT（填充和解除许可权限）比REQUIRED（仅限填充权限）更高的权限，所以REQUIRED不是最高级别。

枚举将如下所示：

/** NO permissions.
 *     Presentation: "hidden"
 *     Database: "no access"
 */
NONE(0),

/** VIEW permissions.
 *     Presentation: "read-only"
 *     Database: "read access"
 */
VIEW(1),

/** VIEW and POPULATE permissions.
 *     Presentation: "required/highlighted"
 *     Database: "non-null"
 */
REQUIRED(2),

/** VIEW, POPULATE, and DEPOPULATE permissions.
 *     Presentation: "editable"
 *     Database: "nullable"
 */
EDIT(3);

从底层（数据库约束），创建一个要访问的字段的映射。然后，该地图在下一层更新（进一步限制）（业务规则+用户权限）。最后，如果需要，顶层（表示规则）可以再次进一步限制地图。

重要提示：必须对地图进行处理，以便只允许访问减少以及后续更新。应该忽略尝试增加访问权限的更新，而不会触发任何错误。这是因为它应该像访问应该是什么样的投票系统。实质上，如上所述的随后的访问级别分层可以按任何顺序发生，因为一旦所有层都投票，它将导致每个字段的访问级别低水位标记。

后果：

1）表示层CAN隐藏数据库指定的只读（VIEW）字段的字段（设置访问NONE）。

2）当业务规则表明用户至少没有VIEW访问权限时，表示层不能显示字段。

3）如果数据库说它只是“必需”（不可为空），表示层不能将字段的访问权限移动到“可编辑”（可空）。

注意：应该制作表示层（自定义显示标签），通过阅读访问地图来呈现字段，而无需任何“if”语句。

在提交验证期间，也可以使用用于设置显示的相同访问映射。可以编写通用验证器来读取任何表单及其访问映射，以确保遵循所有规则。

Answer 3

我经常发现这是唯一真正简单易懂的方法，因为您的界面需要根据他们可以完成的信息和编辑级别进行修改。

我确实发现，根据需要，如果您计划移动到不同的表示级别，可以通过将角色信息传递到业务级别来插入“无法编辑”信息。但这增加了复杂性，如果你只是为一个界面构建，那么很可能是过度杀伤

Answer 4

我以更多OO方式执行此操作的第一直觉是处理您的角色及其实现（控制权限读/写/等）是为您的角色使用抽象工厂模式。如果您愿意，我会很乐意解释我所说的内容的细节，但网上可能有900个例子。这是one link（免责声明：这是我的博客，但确实恰好谈到了使用抽象工厂的角色）

使用这样的东西，您可以使用许多方法为每个业务对象属性显示正确的控件，并使用正确的属性（读/写/隐藏/显示/等）。

Answer 5

对于网站菜单，我们可以使用Sitemaps根据用户角色设置不同的菜单。对于像Buttons这样的控件，我们必须使用它们的Visible属性来隐藏它们。我认为一个好主意是创建服务器控件（Button）并公开Role属性。如果用户没有正确的角色，这将隐藏Button。

控制表单字段访问的最佳实践

5 个答案: