超越CRUD的鋰應用程序

Question

這或多或少是過去Stack Overflow問題的以框架為中心的版本，該問題是關於MVC應用程序的大多數介紹性材料如何在模型，視圖和控制器之間呈現緊密耦合。 例如，您將擁有一個由用戶控制器修改的用戶表，用戶控制器又將過濾后的數據推送到用戶視圖。 我的印象是很多MVC框架也傾向於反映這種模式。 這一切都很好，很好，但除了用HTML表單構建和顯示單調的事物列表之外，它從來沒有真正引導我。

現在正在研究的MVC框架是Lithium ，它作為巧妙的PHP5.3編碼技術的案例研究似乎非常有趣。 一方面，Lithium有一個Model類，它提供了圍繞單個表的包裝器對象，並抽象出一些簡單的查詢。 另一方面，它有一個很好的約定，即路由URL到控制器對象上的方法調用，然后呈現給顯示模板。

但是在這期間，我發現自己不知道將表A中的數據與表B到Z中的數據相關聯的所有有趣邏輯放在哪里。或者至少，我不知道在哪里放置這樣的邏輯的方式與框架的設計一致。 根據我的理解，Lithium的Model抽象除了消除一些行級插入/更新/刪除樣板外沒有什么作用，控制器/視圖架構似乎主要是關於用戶界面。 我不想在接收來自URL請求的路由函數調用的同一個Controller類中放置大量業務邏輯。

我的直覺是用一堆我自己的代碼填補空白，這些代碼或多或少完全存在於框架之外。 我不確定我是否應該期待更多，但考慮到Lithium中其他所有內容的結構是如何嚴格的，它感覺某種程度上不令人滿意，就像我剛剛推出了自己的樣板減少代碼而沒有花費很多資源來解決這個問題。一個大框架。

我在這里錯過了什么？ 是否有推薦的架構或哲學來使用這種類型的框架？

Answer 1

你必須要記住的一件事就是沒有生產就緒版本（盡管有些網站正在生產中使用它）。 現在主要的缺失特征是模型關系。 有了關系，我認為你的問題會得到部分回答，因為這是創建更復雜應用程序的重要組成部分。 您可以查看x-data分支，其中關系的工作應該在哪里進行。

對於編寫域邏輯的第二部分，簡單的答案是“在模型中”。 例如，請參閱擴展模型功能的這個（相當無用的）示例。 另一個值得關注的例子是開源迷你應用程序Analogue，它是使用中少數工作開放的鋰的例子之一。 Analogue模型類顯示了一個稍微多肉的模型。

最后是連接M，V和C之間的點。鋰控制器應該主要將作業委托給模型，並且如果需要可能重新構造輸入數據。 使用Post模型，PostsController和views / posts / add，index等的簡單示例並不意味着您必須只有Post :: all（）。 PostsController :: view需要加載一組Comment模型。

當然，你會在那里拋出很多自己的代碼！ 否則它不會是一個應用程序。 但是保持域邏輯與模型緊密相關。

• 需要驗證博客帖子是否有唯一標題？ 寫一個驗證器。
• 需要確保用戶具有對帖子的寫入權限嗎？ 覆蓋save方法並對其進行驗證，或對其進行過濾。

但我認為我們需要等待關系到達並發布1.0版才能完全判斷如何最好地解決Lithium中的結構化應用問題。