我的简单数据模型： 用户可以创建文章，这使他们成为此特定文章对象的 所有者 。 用户还可以邀请其他用户为文章做出贡献，这会使其他用户 特定文章的贡献者 。
因此，有角色所有者和贡献，并且资源 文章
现在我的问题是，如何使用ZF2的ACL和BjyAuthorize来实现这种结构？我在这里很困难，因为用户的角色对资源 文章 并非全局有效，但必须分配给单个 文章 实例。
答案 0 :(得分：0)
<强>一般
我认为，ZF2 ACL的优势在于根据角色结构继承权限，并且存在ACL感知模块，如MenuHelper。
如果您不需要继承或其他 - ACL-aware - 模块，您可以在没有ACL模块的情况下创建一个非常简单的解决方案。
解决方案1. - ACL
资源，角色和特权只是数据。因此，当您创建授权结构时，角色的含义取决于您在数据库中存储的角色或作为角色放置的内容。
Acl对象的isAllowed方法也只是您创建的数据结构（角色，资源和权限）的验证基础，您可以决定如何处理这些信息。
什么 - 我认为 - 您需要的是和对象访问控制机制[此用户/用户组（=角色）可以写入/读取（=权限）此特定对象（=资源）]除了功能访问控制[可以这个user / goup of users（= role）write / read（= privilege）这种对象（= resource）]。
因此，如果您将文章存储为资源，请将方法（写入，读取，删除等）作为权限进行连接，并为给定用户/组创建与这些权限的关系，您已实现目标。
解决方案2. - 带断言的ACL
如果您在文章中存储一个贡献者用户数组，您可以在创建＆＃34;允许结构＆＃34;时使用此数组中存在的检查用户作为断言。
解决方案2.1。 - 带有断言的ACL - 在单独的表中
您可以将贡献者存储在一个单独的表中，并与Article表连接。
解决方案3. - 序列化的贡献者阵列
如果您不需要强大的ZF2 ACL背景，您只需检查文章中存储的贡献者数组中是否存在用户。
我更喜欢解决方案1.因为它集中管理的AC，但我也看到解决方案2的专业人士。 （解决方案1.混合角色和用户定义，但我已经看到了组和用户对象的混合，所以这不会让我感到烦恼。:)）
列出文章
另一件事也是要考虑：列出文章，一个可以编辑（贡献者）。 用foreach检查所有文章总是在那里。使用更多/更少的直接数据库查询会破坏ZF2 ACL理念。如果你需要分页......这是一个问题。 ：）
还有许多其他解决方案（以及它们的组合）。要找到合适的人，你也必须考虑文章的数量。如果为role / resource / privilage表中的每篇文章的每个贡献者存储行，它们可以非常快速地增长。