許可權ID等常量應該在mvc架構的哪裡合適？

在mvc經典架構之上，我的c層是邏輯控制，service層負責具體業務實現，model層只有service層有權利調用，service層只有c層有權，db handle，orm等與資料庫互動的，只有model層有權使用。

現在原來的系統有許多permission id，都是用數字硬式編碼。我想著用一個常量類或者配置來解決，但配置的開銷太大，用枚舉常量的話，這部分應該處於一個什麼樣的未知呢？真怕被過度設計了。

怎麼樣避免過度設計，同時讓我的常量(likes)處於更恰當的未知。比較通用一點的？ 大家都怎麼做的？

目前的想法是：

model層，內建一個permission provider class

吐槽一下segmentfault的標籤bug。

回複內容：

在mvc經典架構之上，我的c層是邏輯控制，service層負責具體業務實現，model層只有service層有權利調用，service層只有c層有權，db handle，orm等與資料庫互動的，只有model層有權使用。

現在原來的系統有許多permission id，都是用數字硬式編碼。我想著用一個常量類或者配置來解決，但配置的開銷太大，用枚舉常量的話，這部分應該處於一個什麼樣的未知呢？真怕被過度設計了。

怎麼樣避免過度設計，同時讓我的常量(likes)處於更恰當的未知。比較通用一點的？ 大家都怎麼做的？

目前的想法是：

model層，內建一個permission provider class

吐槽一下segmentfault的標籤bug。

既然層次劃分那麼清楚，哪層用到就放哪層唄。
另外放設定檔也可以的，為什麼說設定檔開銷大？

一般常量不都是放在config中的嗎？用的時候就直接調用，這樣的開銷會很大嗎

