PHP：分離業務邏輯和表達邏輯，值得嗎？

可能重複：
Why should I use templating system in PHP?PHP：分離業務邏輯和表達邏輯，值得嗎？

我只是好奇，有多少開發商真正做到這一點？

直到現在我還沒有，我只是好奇它是否真的有助於使事情看起來更清潔，更容易遵循。我聽說過使用像Smarty這樣的模板引擎，但我也聽到了相反的情況。他們只是造成不必要的開銷，實質上就像學習一種新語言。

有沒有人在這裏有模板經驗？你對他們有什麼感受？對大項目有幫助還是浪費時間？

附註：我工作的公司沒有設計師，只有兩名開發人員在這個項目上工作，負責重新設計/升級。我也使用了一點AJAX，這會導致模板引擎出現問題嗎？

來源

2009-07-06 MackDaddy

查看http://stackoverflow.com/questions/436014/why-should-i-use-templating-system-in-php – 2009-07-06 19:19:16

這種做法不僅使代碼看起來更清潔，它也有許多長期和短期的好處。

組織代碼永遠不會出錯。首先，如果其他人不得不在你之後繼續閱讀，那麼維護起來就容易多了，而且閱讀起來也更容易。我之前和Smarty一起工作過，它很好，它可以讓設計人員避免干擾程序代碼。

使用模板系統和框架將使它更容易完成任務。你可以遵循的經驗法則是DRY（不要重複自己）。框架可以幫助你實現這個目標。

你可能想看看MVC，這是這些框架基於的模型。但是你可以實現這個設計結構，而不必使用框架。避免學習曲線。對於像Zend這樣的框架，學習曲線比其他的要多得多。

我發現Code Igniter是相當容易使用，他們有一些非常有用的視頻教程在他們的網站上。

祝你好運！

來源

2009-07-06 19:24:07

其實它是需要與視圖分離的業務邏輯。您可以在視圖內使用php作爲「模板語言」。

你可以在我認爲的任何模板引擎上使用ajax。

編輯

我原來的響應處理的問題是否使用模板引擎或不生成的HTML。

我認爲，只要您將業務邏輯與表示邏輯分開，php就足夠用於模板任務。

值得這樣做即使是簡單的頁面，因爲它使您能夠：

隔離是從代碼應用程序的大腦這是臉的代碼，所以你可以改變的臉，沒有用腦搞亂，也可以提高大腦沒有制動長相
分離80蟲子％在你的代碼的20％
創建可重用的組件：你可以指定不同的演示代碼到同樣的b使用代碼，反之亦然;
分開設計要求（演示代碼），這也通常都與不同的人對客戶端的擔憂，以及對承包商側
使用不同的不同的人的功能要求（業務代碼）的擔憂人們編寫業務代碼和表示代碼;您可以讓設計人員直接處理演示代碼，並使用最少的php知識;

的簡單解決方案，它模仿MVC和不使用對象可以是：

使用單個控制器PHP文件，其通過接收所有請求。httpdaccess文件;
控制器決定哪些業務和演示代碼，請根據要求
控制器然後使用一個包含語句，以包括商業PHP文件
業務代碼做它的魔力，然後包括展示的php文件

來源

2009-07-06 19:22:17

或多或少我要說的。我認爲PHP最初是作爲一種模板語言開發的，所以不需要添加其他圖層，而是將所有非表示性代碼分開。 – mpen 2009-07-06 19:32:55

PHP 是模板引擎（或者如果您願意，超文本預處理器）。當HTML與PHP邏輯混合在一起時，它的維護變得非常困難，這就是爲什麼您需要單獨定義函數來構建各種部分，並且只需從嵌入在HTML中的短函數調用來構建頁面。完成這樣的工作後，除了分隔符的選擇之外，我沒有發現Smarty和原始PHP之間有很大區別。

來源

2009-07-06 19:25:41

Smarty和其他php模板框架實際上只不過是編譯到PHP而已，並且在大多數情況下它們還會緩存它們的結果以實現更快的處理。您可以自己完成這一切，但如果您查看Smarty生成的已編譯模板，並與您創建的原始Smarty模板進行比較，則可以看到其中一個比另一個更具可讀性。

來源

2009-07-06 19:29:59

我現在主要編寫mod_perl，並在我們正在進行的項目中途開始使用模板（HTML :: Template）。如果我必須再次作出決定，我會從一開始就使用模板 - 稍後重寫模板使用起來會很乏味，但由於您獲得更好，更簡潔的代碼，所以很有意義。對於任何大於2-3頁的php，我也會使用一些模板引擎。

來源

2009-07-06 19:31:40

像Smarty這樣的模板引擎的一大優點是，非開發人員可以使用它來嵌入前端使用的必要邏輯（實際上，除了最簡單的邏輯和顯示之外，網站）。但是，如果開發人員是維護頁面的人，那麼在我看來，使用PHP會更可取。

如果分離出較大的邏輯塊併爲循環和每個流控制語句保持一致的模式（即不使用打印語句，或者僅對單行打印使用打印語句等）好好地。

來源

2009-07-06 19:32:23 null

分離顧慮對於任何類型的軟件開發來說都是非常重要的租戶，即使在網絡上也是如此。太多次我發現人們把所有東西都放到儘可能少的文件中，並稱之爲一天。這當然是錯誤的做法。如前所述，這將有助於代碼的可維護性，但更重要的是，它可以幫助您閱讀代碼。當一切都分開時，你可以輕鬆地思考。

代碼點火器，我發現，一直是使用PHP最簡單的學習框架。我幾乎開始了我目前的工作，並在幾天之內就開始使用它，從未聽說過它，並非常有效地使用它。我根本不認爲它是另一種語言。基本上，使用框架迫使我以一種可管理的方式組織事物，並且添加的功能對於使用jQuery的插件等或使用Java導入包來說是非常複雜的。認爲它像學習另一種語言似乎幾乎是愚蠢的。

因此，總之，組織組織。不過請記住，抽象層次很荒謬。一個經驗法則是，一個類（或者我們的例子中的文件）應該做的很好。這並不意味着它是一個環繞打印的類，而是接受一個字符串，使用複雜的算法對其進行格式化，然後打印出來（這只是一個例子）。每個班級都應該做一些特定的事情，你可以在沒有任何框架的情況下做到這一點然而，MVC的優點在於，它可以讓你進一步組織事物，不僅僅在單個類級別上，而且在「包」，即模型，視圖和控制器的層面上（至少在這些框架的情況下;還有其他的方式來打包項目）。所以，現在你有單獨的課程可以很好地完成任務，然後你可以將它們與類似的課程分組在一起，從而做得很好。這樣，一切都保持得很乾淨，易於管理。

將事物組織成類然後打包後，最後一層考慮的是如何在包之間訪問這些類。當使用MVC時，訪問通常會轉到模型< - >控制器< - >查看，從而將模型（通常是PHP世界中的數據庫內容和「業務」代碼）從視圖中分離出來用戶，並將其傳遞給控制器，然後控制器將從模型中獲取更多信息（如有必要），或者對輸入信息執行其他操作）。這種控制器的工作原理類似於另外兩個包之間的交換機通常是。同樣，還有其他方式可以使用包裝等，但這是一種常見的方式。

我希望有幫助。

來源

2009-07-06 19:41:14 Peter

PHP：分離業務邏輯和表達邏輯，值得嗎？

回答

相關問題