## 目录结构 应用是ThinkCMF中最大的独立模块,一个应用会包含自己的数据库表,控制器,模型和视图.它的核心代码位于 `app`目录下,以` portal` 应用为例([请到演示仓库下载](https://github.com/thinkcmf/demos)) ``` thinkcmf 根目录 ├─api api目录 ├─app 应用目录 │ ├─portal 门户应用目录 │ │ ├─controller 控制器目录 │ │ ├─model 模型目录 │ │ └─ ... 更多类库目录 │ ├─ ... 更多应用 ``` 同时一个应用也会有自己的视图,但在 ThinkCMF 中一个应用会分为前台视图层和后台视图层; ``` thinkcmf 根目录 ├─public WEB 部署目录（对外访问目录） │ ├─themes 前后台主题目录 │ │ ├─admin_simpleboot3 后台默认主题(以admin 开头) │ │ │ └─portal 应用视图目录 │ │ │ │ ├─admin_article 后台文章管理控制器视图目录 │ │ │ │ ├─admin_category 后台文章分类管理控制器视图目录 │ │ │ │ └─admin_page 后台页面管理控制器视图目录 │ │ └─simpleboot3 前台主题 │ │ │ └─portal 应用视图目录 │ │ │ │ ├─index.html 应用前台首页 │ │ │ │ └─ ... 其它前台文件 ``` > 注:应用后台主题目录以 admin开头 以上就是 cmf 应用的结构体系,有人会觉得不爽,估计会有以下几点: 1.为什么和 tp5.1默认的项目结构不一样,tp5.1不是把应用放 application 目录下? > 老猫说: tp5.1足够灵活,应用目录是可以轻松配置的,之前的 thinkcmfx 也是放 application 目录,但老猫觉得这次优化就要想的更细点,现在既然都以 namespace 为主了,如果还把应用放 application 目录,命名空间又是`app\portal`这样的,为什么不直接把application 目录名也改为`app`呢! 2.为什么非要把后台控制器带上前缀`Admin`呢? > 老猫说: 如果你能分清是前台后台控制器,你不想带也没事,加个前缀项目结构变的清楚不好吗? 3.为什么非要把前台和后台模板分开呢? > 老猫说: 没办法就这么任性! a.其实分开是有更多好处的,前台后台本来就是风格不统一的,把什么放在一起反而会让人烦,最后你都没法分清是前台后台的 css了,还不如彻底分开. b.分开以后前后台实现多模板的功能就方便了,多模板在很多场景是很有用的,两年了网站要大改,老板说别用 bootstrap 了,我们换个彻底吧,你只要新建一个目录,自己写好放上去就好了 c.前台多模板了,对于一些前台好的,他完全可以把自己的模板做好打包销售出去,后台多模板也一样呀! ## 数据库表结构 应用数据表命名时,我们希望你最好加个表前缀,如 `portal_`这样会让你的数据库表结构也很清晰, ``` cmf_portal_category (portal应用 文章分类表) cmf_portal_category_post (portal应用 分类文章对应表) cmf_portal_post (portal应用 文章表) cmf_portal_tag (portal应用 文章标签表) cmf_portal_tag_post (portal应用 标签文章对应表) ``` ## 应用化才是你发展的重点 应用化是你把业务分开的一个不错的方式,基于 cmf 提供的基础功能,你不用再关心权限,用户等最基础的东西,只要根据自己的应用场景增加应用就可以了,比如:论坛,商城,话题...,甚至你可以在自己的行业里做应用. 如果你的应用有足够大的通用性你完全可以把它做成一个产品,对于已经使用过 cmf 的用户,只要把你的应用复制安装过来,就能用了! 所以应用化,你可以最方便的享受 cmf 的更新,同时也可以以应用形式发布自己的产品,即时是你内部自己用,项目维护发展也足够清晰! > 小夏说: >别再改 cmf 的核心代码了,不好升级,改了,再也不会有老猫这个免费,还天天做客服的高级搬砖工了! 管好你自己的应用就好了!