今天的主題應該放在第一天（或是最後）
但畢竟我是邊寫邊研究
所以現在寫這個題目比一開始有把握
之所以不壓在後面而現在就寫
自然是因為今天想不到其他內容了！

這一篇文章的意義在於
如果未來出了一個新的框架
只要比較是否擁有下列重要元素
或者有更佳的替代方案即可（畢竟典範不斷轉移）
比依靠直覺或單方面說法判斷一個框架的優劣更加可靠

這邊是以全能型的框架為依據
所以輕量級（Sinatra、Flask、Slim...）框架自然不需要符合這些標準

MVC

這在前面Django與Rails的比較中就談了不少
儘管在Django稱之為MTV(Model-Template-View)
但資料、邏輯、視覺分開處理概念是相同的
毫無疑問的是現代框架的主幹

RESTful router

詳見RESTful API設計模式談現代網頁框架
遺憾的是Django並沒有預設採用RESTful的設計
必須引入外掛

至於router則是所有框架都有的設計（儘管Django稱為urls.py）
雖然實作上略有不同

• Laravel允許將邏輯寫在router層，看起來會跟輕量級的框架非常像（如Sinatra）。而且預設就依照用途不同分為不同檔案。
• Django分為兩層，專案與app都可以設定urls.py (router)
• Phoenix與Rails一樣都是同一個檔案，但是多了pipeline的設計，類似Laravel的Middleware，可以在controller之前實作其他的邏輯。

ORM

ORM (Object-relational mapping ) 在之前的Phoenix與Laravel的部分都有介紹過
這邊就不重複，有興趣的人可以看我之前的文章
除了少數硬派的人堅持自己寫SQL外
大部份框架都選擇接受ORM
這也是時代潮流的一部分

Migration

透過migration來實作資料庫結構異動
而不是直接寫sql語法去變更
好處是資料庫異動可以納入版本管理，壞處無
所有框架都採用且名稱也相同
不需多做解釋

project consloe

雖然與專案並不是直接相關
但卻是專案開發上相當重要的工具
一個可以與專案資料與結構互動的指令介面
寫任何邏輯之前，幾乎都會先在這邊做小規模驗證
然後逐步疊加成為實作方法

很高興所有專案都有接納並實作這個功能
只是名稱各異
不同框架間的比較請見「project console (CLI)比較簡析」

command line generator

雖然也可以用編輯器新增檔案
但被Rails寵壞以後，沒有這個功能還是覺得很老土啊
可以產生新的migration、model、controller、view、tester的指令
一樣是加速開發效率的工具

frontend mid-layer

不管框架使用哪一種語言
幾乎都會有的需求，產生html等前端之前需要簡單的邏輯應用
例如rails的erb與Laravel的blade
實務上不可或缺的工具

testing

在當代開發的情境中
測試沒完成等同於功能沒完成
雖然每次閒聊時問大家專案有沒有寫測試
幾乎都會得到一臉苦笑

雖然也有人說測試接近一種信仰
跟助人為善或早睡早起一樣，是一種道德
但至少框架預設有這個內容
就代表著這是一個善良與勸人為善的框架
不是嗎？

洋洋灑灑列了8點
幾乎都是當前業界公認的最佳實務
雖然並不是說全都符合就一定是神兵利器
但假如缺乏很多元素（除非是輕量級）
那你可能就需要考慮是否選對框架囉！