2009-06-04 24 views
0

我想了解如何为我正在编写的应用程序实现用户/角色关系。持久层是Google App Engine的数据存储,它为可以完成的工作提供了一些有趣的(但通常是有益的)限制。任何想法都表示赞赏。用户和角色的上下文

保持事情非常具体可能会有帮助。我希望有组织,用户,测试内容和测试管理部门(测试记录)。用户可以扮演参与者(测试者),测试材料的贡献者或两者的角色。用户也可以是零个或更多组织的成员。在参与者的角色中,用户可以看到他或她已经接受过的测试的前几次管理。如果该参与者已授予用户授权,用户还可以看到另一个参与者的测试管理。用户可以看到已经公开的测试材料,并且他或她可以在对该用户已经被组织授权的测试的特定管理期间看到受限制的内容作为参与者。作为组织的成员,用户可以看到贡献者角色中的受限内容,他或她可能也可能不能编辑内容。每个组织应该有一个或多个管理员,可以确定成员是否可以查看和编辑内容并确定谁具有管理员权限。还应该有一个或多个应用程序范围的超级用户可以解决问题并解决问题。组织成员可以看到相关参与者授权他们查看的测试管理机构,如果没有授权,他们可以看到匿名数据。在其他情况下,用户无法看到其他用户的测试结果。

由于App Engine数据存储区中没有连接,因此可能有必要对典型的SQL数据库进行标准化处理,以确保检查权限的查询速度快(例如,确定是否存在链接将被显示)。

我的问题是:

  1. 如何向前推进的呢?为了让模型正确,我应该花费大量时间吗?还是我可以迭代几次,并逐渐增加复杂度?
  2. 有没有人有一些关于如何在这种情况下打破东西的一般想法?
  3. 是否有任何GAE库以兼容这种安排的方式处理角色?

回答

1

我不太清楚,我正确认识你的问题,但我会尽我所能回答:

  1. 我总是觉得迭代编程更容易测试和编写,所以这是我的建议。
  2. 我认为你有必要的实体已经正确划分,但我认为你需要一个额外的实体:Permission,它定义了每个角色可以做的事情,每个角色有零个或多个Permission链接。请记住,对于GAE中的每个多对多关系,您需要定义一个键列表,或者一个单独的实体作为中介。
  3. 不是我所知道的,但是您可能想要调查基于Django的角色系统,并尝试修改基于Django的解决方案(因为Django的时间更长)。你可以用Django攻击GAE,而不是用App Engine Patch
+0

感谢您的帮助。回复1,我绝对更喜欢迭代方法的替代品。但是对于数据库来说,我的经历有些不同,我的感觉是,先把更多的想法放在一起可能是件好事。我注意到GAE数据存储比SQL数据库更难重构。所以我希望弄清楚,有没有人做过类似的事情,可能知道什么平衡点。 Re 3,我正在使用app-engine-patch,但我不认为Django有中间组织(或帐户)的概念。 – 2009-06-04 21:48:58