我目前正在使用數據庫來設置一個頁面對象的自定義框架內工作，該頁面對象包含關於模塊，視圖，控制器等的信息，前端控制器使用該信息來處理MVC內的路由等（顯然）模式。數據庫驅動的前端控制器/頁面管理好還是壞？
在數據庫中處理頁面的最初原因是因爲我們需要能夠從管理界面中實時創建新的着陸頁面，並且因爲我們還需要創建onLoad和onUnload事件，而其他動態對象可以附加。
但是，在昨天閱讀了這個post之後，它讓我懷疑我們是否不應該將此處理移出數據庫，並使其像其他框架一樣驅動所有文件結構和代碼，以便可以在沒有數據庫的情況下測試頁面成爲一個組件。
我目前正在尋找是否廢棄自定義框架，並與標準框架之一併擴展它（這是現在最有可能的），但我想知道是否擴展框架來處理頁面請求通過數據庫就像我們現在或如果我們應該簡單地使用框架隨路由/處理機制？
通常我對「玩具」應用程序允許的內容相當寬鬆，但我認爲不管怎樣都應該避免一些不良習慣。數據庫是功能強大的工具，通過存儲過程使用合理強大的語言來完成您需要做的任何事情......但它們確實應該用於存儲和擴展數據訪問以及實施低級別數據一致性規則。
將業務邏輯放入數據層是很常見的事情，但關注點的分離確實有助於應用程序在其整個生命週期內的可維護性。
請注意，使用數據庫存儲頁面模板而不是文件系統沒有任何問題。兩者之間的界限將在未來進一步模糊，並且我有一個系統，所有模板都在數據庫中，因爲低預算託管的問題以及如何動態生成內容需要保存。只要你的框架可以很容易地從一個文件或一個字段中提取出一個模板並處理它們，那麼這兩種模式都沒有關係。另一方面，昨天的帖子是關於從數據庫直接生成UI層元素直接（至少，這是我如何閱讀它），而不是模板的不尋常的存儲位置。 由於所提及的原因而深受關注......數據庫被鎖定到網絡應用程序，並且僅限於網絡應用程序。
另一方面，如果您的系統運行良好且易於擴展，絕對不要接受其他人的建議。每個用例都略有不同。如果您的可維護性不受影響並滿足業務需求，那就足夠了。