## 目錄結構 應用是ThinkCMF中最大的獨立模塊,一個應用會包含自己的數據庫表,控制器,模型和視圖.它的核心代碼位于 `app`目錄下,以` portal` 應用為例 ``` 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默認的項目結構不一樣,tp5不是把應用放 application 目錄下? > 老貓說: tp5足夠靈活,應用目錄是可以輕松配置的,之前的 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 的核心代碼了,不好升級,改了,再也不會有老貓這個免費,還天天做客服的高級搬磚工了! 管好你自己的應用就好了!