Web應用程序設計分層規則和最佳實踐

-2

Web應用程序通常設計爲分層。通常會有一個Repository（Dao）層，一個Service層和一個Control（Web處理）層。控制層使用服務層，該層依次使用存儲庫層。通常你會直接使用Repository圖層看到Control層。Web應用程序設計分層規則和最佳實踐

也很普遍的是使用其他服務的服務。很多時候，所有服務都從基本服務類繼承，該類將包含對所有Repository組件的所有引用。

所以我的問題是如何以及爲什麼要設計你的服務器端應用程序（按照層次）以及你對它們應用了哪些規則？

這些層和這些規則的普遍接受的理由是什麼？

你認爲哪些規則應該被認爲是「壞習慣」？

你認爲什麼規則很重要？

你嘗試過這方面的新工作嗎？

作爲一個例子，我一直在考慮的是將服務分類爲「主要」或「次要」。此處的規則是主要服務不能使用輔助服務。我希望這可以緩解一些混淆，其中有大量使用其他服務的服務使用其他服務。儘管如此，仍然是一項工作/思考。

這個問題很可能太寬，無法很好地適應進入SO的Q/A格式;這可能會解釋downvote。 –

你的問題太模糊，一般。我們只能回答這裏的具體問題。 – Shlublu

是的，你可能是對的，但實際上只是一些簡單的規則適用於這個領域。給出的答案提供了這一點。我應該在這個問題上更具體一些。 –

我使用你描述的三個層，但沒有任何基礎類爲我的服務，並且只聲明其他服務和存儲庫我實際使用作爲我的服務中的字段：這使得依賴關係清晰。

理據分層：

責任的分離
子服務有時需要能夠啓動一個新的事務
事務劃分，或者只是重用多種服務內部的業務邏輯
可測試性：如果測試控制器僅依賴於定義明確的服務，則更容易測試。如果測試服務僅包含業務邏輯並且沒有持久性邏輯，則更容易。如果他們所做的只是持久性（數據庫查詢），則測試存儲庫會更容易。
能夠爲所有服務或所有存儲庫添加攔截器（使用AOP）以檢查訪問權限，衡量性能等。

不良做法：具有

2011-09-14 13:03:46

這一切都取決於應用程序的複雜性。一個非常簡單的應用程序可能只有Control，Service和DAO層。正如你所說，更復雜的應用程序可能具有多個服務層，並且它們可以是遠程通信。

但是，恕我直言，DAO層不應暴露供應商特定的API。用戶應該對下面使用的技術透明。休眠/ EJB等

2011-09-14 13:02:51 Gaurav

回答