CFMX開発 フレームワーク比較表２

CFMX用フレームワーク比較表で、Fusebox、Mach-II、Model-Glueの比較をしていたことを思い出して、もう比較表を見直してみました。
やっぱり、Fuseboxは敷居の低さ、Mach-IIはプロフェッショナル用、Model-Glueは両方のいいとこ取りって感じです。

各比較項目のうち、1行目は共通点、2行目以降は差異点です。
（以下、各フレームワークの略称　FB:Fusebox/M2:Mach-II/MG:Model-Glue）

・XML
All use XML config files
FB has multiple XML,  M2/MG has one XML
・MVC
Can use MVC
FB allows but does not enforce, M2/MG pretty much forces it
・MVC Structure
Model/View directories
FB typically has controller circuit directory, M2/MG has implicit controller in framework
・CFCs
Can use CFCs
FB allows but does not enforce, M2/MG pretty much forces it
・Plugins
All have plugin points
FB has more plugin points, M2 distinguishes events and views, MG has simple request/queue model
・Access control
All have private / public concepts
FB has per circuit and per fuseaction as well as roles-based model, M2/MG has per event access only
・Auth / Security
None
FB has roles support builtin, M2 provides a sample filter, MG is free form
・Install / Config
One-stop core files, basic properties in XML file
One-stop core files is brand new in FB41, FB provides finer control over framework behavior, MG has a simple framework control model
・Modularity of Application
None
FB has circuits to partition large applications
・Modularity of Site
None
M2 allows multiple sub-applications to share application scope
・Commonality
Can explicitly invoke fuseactions / announce events / add results to handle common functionality  FB has per-circuit pre-/post-fuseaction hooks, providing framework level support for commonality
・Views
All encourage views to contain “only HTML” (no logic)
FB/MG lets you include a view directly, M2 requires that you declare all views in XML
・Handler Model
All declare 'handlers' for 'events' in XML
FB is a static, explicit invocation model, M2 is a dynamic, implicit invocation model, MG is somewhere in between
・Data bus
Can use request scope as data bus (but it's not always best practice) – MG uses event object  　FB allows variables scope as data bus, M2 allows event object as data bus, MG enforces event object as data bus
・Global data
None
FB has fusebox.init.cfm, M2 uses either 《property》 tags or plugin (or both), MG has settings
・Model CFC Structure
Most CFC methods could be the same
FB uses standard init() construction controlled by explicit code in fusebox.init.cfm or circuit, M2 reserves init() and uses a managed configure() method to initialize CFCs – with no arguments – and CFCs must extend the framework, MG has base controller init() method
・Conditional logic
None
FB has some conditional logic in the XML grammar, M2 requires conditional logic placed in CFCs, MG requires controller CFCs
・Model Actions
All have the concept of separating business model logic from presentation logic
FB allows a model action to set multiple outputs, M2 uses strict call/return semantics so each action can have only one result, MG allows a model to set multiple outputs via event object
・Model Queries
None
FB specifically separates out persistence operations (by a naming convention on files), M2/MG draws no distinction between actions and queries

ちょっと長かったかな？