权限ID等常量应该在mvc架构的哪里合适?

WBOY
發布: 2016-06-06 20:17:41
原創
1528 人瀏覽過

在mvc经典架构之上,我的c层是逻辑控制,service层负责具体业务实现,model层只有service层有权利调用,service层只有c层有权,db handle,orm等与数据库交互的,只有model层有权使用。

现在原来的系统有许多permission id,都是用数字硬编码的。我想着用一个常量类或者配置来解决,但配置的开销太大,用枚举常量的话,这部分应该处于一个什么样的未知呢?真怕被过度设计了。

怎么样避免过度设计,同时让我的常量(likes)处于更恰当的未知。比较通用一点的? 大家都怎么做的?


目前的想法是:

model层,内置一个permission provider class

吐槽一下segmentfault的标签bug。

权限ID等常量应该在mvc架构的哪里合适?

回复内容:

在mvc经典架构之上,我的c层是逻辑控制,service层负责具体业务实现,model层只有service层有权利调用,service层只有c层有权,db handle,orm等与数据库交互的,只有model层有权使用。

现在原来的系统有许多permission id,都是用数字硬编码的。我想着用一个常量类或者配置来解决,但配置的开销太大,用枚举常量的话,这部分应该处于一个什么样的未知呢?真怕被过度设计了。

怎么样避免过度设计,同时让我的常量(likes)处于更恰当的未知。比较通用一点的? 大家都怎么做的?


目前的想法是:

model层,内置一个permission provider class

吐槽一下segmentfault的标签bug。

权限ID等常量应该在mvc架构的哪里合适?

既然层次划分那么清楚,哪层用到就放哪层呗。
另外放配置文件也可以的,为什么说配置文件开销大?

一般常量不都是放在config中的吗?用的时候就直接调用,这样的开销会很大吗

相關標籤:
php
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板