2011-04-06 61 views
1

我有一些項目(一些商業的,一些沒有),其中需要場和資源級別的訪問。當然,使用和貢獻ORM項目相當於重新發明輪子,但是我一直無法找到具有任何訪問控制層的項目;它們似乎大部分都是由域對象決定的,而這些類不能從超類繼承。開放源代碼的ORM與PHP的訪問控制

分叉主義可能是可能的 - 但是,我不想獨自潛水。

回答

1

我的ORM選擇一直是Propel(v1.5),我覺得它更輕,更快,更易於理解。它還具有自定義行爲,這可能是您的訪問控制插件的起始階段,至少對於資源而言。

你可以看到關於行爲的一些文檔herethis維基解釋瞭如何構建自己的。

希望我能幫助

+0

我還通過推進看着(仍然通過源讀取實際),但它並沒有解決訪問控制更多而不是學說,並且需要Zend框架 - 如果你已經承諾在域名的其他框架上增加一個沉重的部分。 – 2011-04-06 23:51:30

+1

你在哪裏發現Propel需要Zend Framework? AFAIK並非如此。 – 2011-04-07 07:32:32

+0

我必須穿過我的電線 - 不知道現在哪一個需要... – 2011-04-09 04:01:54

1

創建DB結構,用戶訪問控制,以及構建代碼,這將使定義的規則有效,是不是ORM工作(它會幫助你做到這一點,但它贏得了不會爲你做)。

然而,這需要訪問控制的頻繁(命名爲ACLRBAC;似乎你正在尋找一個ACL),以及一些項目已經出現,它創建所有DB結構爲,例如sfGuard(Symfony)或Zend_ACL(Zend Framework)。

檢查這些SO線程太:

+0

我們要做的是RBAC更細粒度,以及我無法看到如何將它與其分開的原因ORM是指無論域對象是否加載到工作模型中,還是某些字段都加載到自定義查詢/映射中,字段級訪問控制都需要工作。 – 2011-04-06 23:31:55

+0

由於我們處理大量敏感數據,因此內部控制要求我們不允許一個人訪問特定的組合,因此ORM是唯一足夠低以在現場級別實施訪問控制並且足夠高了解對實際資源的影響(主要是與域對象一對一)。 – 2011-04-06 23:34:02

+0

對不起,我已經完全忽略了你的問題中的「字段」訪問控制要求......經過一些谷歌搜索後,我沒有發現任何有趣的東西。您應該嘗試一下David Conde的答案的「推動行爲」的想法(因爲您不必「分叉」Propel,即使在添加代碼作爲行爲後仍然可以升級它)。 – 2011-04-07 07:47:31