業務層的jsp

Question

爲什麼我們不應該將JSP用於業務層？

是表現嗎？ 還是僅僅是一個好習慣？ 當然可以重用是其中一個原因。除此之外，爲什麼我們應該將jsp用於業務層呢？

Answer 1

通常的原因是關注點分離。您應該輕鬆修改演示文稿而不影響業務層。

Answer 2

可重用性和可維護性是一些巨大的問題。

考慮下面的情況;

1. 假設你想創建一個iPhone 版本的應用程序，你必須 到端口的所有業務邏輯 的iPhone，現在讓我們擁有了 申請一個Eclipse RCP前端和基於閃存;然後與基於Python的系統集成。

2. 由於業務邏輯和 呈現在同一個文件， 創意Web開發有 學習一些Java，如果他要 不 打破了應用程序創建的最佳接口。

Answer 3

如果您製作的應用程序超過5頁，混合邏輯和演示文稿可能會讓您的生活更加艱難。但是，這是我的一個不受歡迎的觀點 - 對於小型應用程序（甚至是中型應用程序），只需一個「知道他的代碼」的開發人員，就可以將JSP用於buisness邏輯。它可能是jsps放在/action/文件夾中，稍後重定向到演示文件夾，或者它可能與請求來自的jsps相同。我舉了一個例子 - 在開發實踐之初，我基於網絡策略遊戲幾乎完全基於自我發佈jsps。那是5年前。幾個星期前我看了一下我的代碼庫，我可以理解所有的東西。所以，如果你剛剛開始，而且你不想從一個能讓你的學習曲線更陡峭的大框架開始，並且你不希望你的項目變得非常大或者變成商業化的（旁註：我的商業變得商業化然後隨意使用jsps作爲業務邏輯，但需要注意的是在常見情況下這不是一個好習慣。

Answer 4

幾個原因：

1. 重用性：你不能再使用小腳本。
2. 可替換性：不能使腳本抽象化。
3. OO能力：你不能使用繼承/組合。
4. 可調試性：如果scriptlet中途拋出一個異常，你得到的只是一個空白頁面。
5. 可測試性：scriptlet不是單元可測試的。
6. 可維護性：每個saldo需要更多的時間來維護混合/混亂的代碼邏輯。

還有更多，但它歸結爲腳本是壞習慣。

您可以在表示層JSTL和EL做相當多的工作。如果您認爲這兩種方法都不可行，並且您不得不抓取scriptlet，那麼代碼邏輯最終屬於一個真正的Java類。您可以使用一個Servlet類來控制/預處理/後處理請求，您可以使用Filter類來過濾請求，您可以使用DAO類來完成數據庫交互，可以使用Javabean類來存儲/傳輸/訪問數據，您可以使用Domain類作爲業務邏輯，您可以使用Utility類作爲靜態工具。