2013-02-22 35 views
2

我想問一些關於Laravel應用程序中業務邏輯的代碼結構的其他意見,主要是關於行級權限。行級別權限和Laravel應用程序結構

對於那些不知道它的人來說,Laravel是一個PHP的MVC框架,就像Rails一樣。

爲了便於理解,我們假設一個多用戶應用程序,每個用戶都有他自己的專輯和圖片,到目前爲止都非常好。

  • 現在,每個用戶都可以邀請他人協作(通過上傳照片)到他的相冊中。
  • 上傳圖片的相冊的所有者和協作者都可以刪除或更新關於該圖片的信息。
  • 只有擁有者可以編輯相冊並邀請新的合作者。
  • 如果合作者願意,合作者可以自行刪除相冊。

Pinterest應該是類似的很好的例子,但我們的應用程序可能是3到4倍更復雜。 問題是:我應該在哪裏處理這種邏輯?

Laravel提出了一種存儲庫,實體和服務的方法,我可能並沒有完全理解,可能是因爲缺乏很好的例子。所以滿足這些最後期限的首要選擇就是把它全部放在控制器上(ew!)。現在,挖成重構,有許多可能的方式來un'spaghettize我們的代碼:

  • 我見過的人行級執行ACL(看起來有點愚蠢和矯枉過正)
  • 這將有可能轉向車型引入行爲感知對象,而不是唯一的數據容器,像$album->add_photo($photo)和檢查權限在該函數
  • 這也將是可以覆蓋模型的保存方法,並在那裏做那些檢查
  • ,或按照其的Laravel擬建道路單獨關注層

我想,像$album->can_be_edited_by($user)有方法可以簡化航線上的404個錯誤回報顯示不準,隱藏視圖的鏈接,還可以節省你會推薦哪一個模型

前驗證,並且沒有人知道任何簡單,但可以理解的,不使用.NET的存儲庫,實體和服務的例子? 謝謝!

編輯:我想完整的ACL系統會導致過多的開銷,因爲可能有成千上萬的資源與每個用戶相關聯,但每種關聯只有一個角色。例如,圖片將有一個uploader_id和相冊將有一個owner_id

+0

你可能會發現這有點相關:http://stackoverflow.com/q/3430181/727208 – 2013-02-22 08:52:23

+0

你的確是一個相當不錯的答案。儘管目前我們希望避免的是每行ACL,特別是因爲沒有組,並且在最壞的情況下,每個資源有兩種不同的權限類型,其中一個已經被外部'owner_id'鍵限制。我們假設有一個完整的ACL系統會導致過多的開銷。你對層的解釋使我對事物更清楚。 – vFragosop 2013-02-22 21:04:19

回答

0

我可能是錯的,但我認爲ACL是基於對象的權限(即用戶可以或不可以一般刪除照片)。你想要的是更多基於自定義模型的權限(像你所說的行級別),即用戶可以刪除他們自己創建的照片(具體的)。

大多數Laravel軟件包是爲基於對象的權限而設計的,我認爲,但不是https://github.com/deefour/authorizer - 這是一個偉大的隱藏寶石。我們並沒有在我們的項目中使用它,但我發現它確實涵蓋了我們需要的所有基礎。

我們對應用程序擁有真正先進的模型權限,我將它們分散在整個模型中,但我採用了非常「模型化」的非常模型化的方法。在你使用delete的例子中,我會覆蓋你的模型中的delete方法,或者監聽雄辯事件並在那裏阻止它。如果你必須阻止讀/寫某些屬性,你甚至可以通過擴展你的驗證器或者使用自定義的mutators/getters,序列化器或者監聽事件來做到這一點。更多關於哪裏我的問題添加業務邏輯/回答在這裏:https://stackoverflow.com/a/27804817/796437

我仍然在試圖找到最好的辦法,如果我這樣做,我會更新這個 - 但想到我會發布。

+0

也許是倒票的解釋? – 2017-02-26 16:08:35

0

在Laravel中,您可以使用Policies或使用解決方案,如Symfony Voters。 對於Laravel存在相同的軟件包 - Laravel Simple Voters

利用這一點,你可以檢查訪問自定義對象,看起來是這樣的:

Access::isGranted('edit', $post) // current user can edit this post? 

你可以把這個邏輯,以例如,到中間件,如果你想檢查請求轉發給控制器。