我正在創建一個數據訪問對象，以從Google App Engine中爲基於Spring框架構建的Web應用程序（首次爲所有人）檢索信息。DAO（數據訪問對象）最佳實踐 - 我看到使用DAO和Services對象的例子，這裏的最佳實踐是什麼？
我看到一些使用Controller/webapp - > Service - > DAO - > JDO/Google-app-engine模式的示例。
在這種模式中，DAO層是唯一知道JDO的層，因此如果數據存儲區發生更改，該層是唯一需要更換的層。服務層調用DAO層並格式化/操作所需的數據。
我的問題是爲什麼額外的服務層？至少最初它似乎並沒有像服務層那樣增加很多。我自然會認爲只需編寫一個DAO層來封裝JDO請求並操作和返回數據。
有人可以告訴我一個單獨的服務層的理性，這將變得明顯，隨着項目變得龐大和更復雜？
通常情況下，您將DAO放在服務層中，因爲隨着應用程序變得越來越複雜，您將在服務中執行有用和非平凡的操作。例如，您可能會將複雜的數據操作與多於1個DAO進行協調。服務層還提供劃分橫切關注點的API邊界，例如事務管理，授權檢查，性能日誌記錄等。
其將服務抽象爲服務的好處的另一個原因是它可以促進可重用和可維護的組件。當你開始時，你可能會對呈現一些html感興趣。您編寫一個加載一些數據的服務，並處理服務層（表示層）上層的html部分。現在你想站起來一個REST風格的web服務。您的服務層可以重新使用來加載數據;所有你必須擔心的是你的web服務端點返回的json或xml（當然還有REST語義）。
因此，對於簡單的情況，服務層可能會增加一點點，但隨着應用程序的擴展，它們變得有價值，甚至對於保持代碼清潔至關重要。
是的，最初似乎服務層沒有增加太多的等式。但想想這樣。
服務層=您的演示文稿和業務層之間的一個層。
您一定意識到，在圖層之間分離關注始終是件好事。您的服務層可以映射到不同的業務域，表示層，而不用擔心DOA層的使用方式。
您可以將此視爲兩個其他圖層之間的邊界，在這種情況下爲演示文稿層和業務圖層之間的邊界。表示層中的代碼通常實現用例。典型的用例是用戶執行的一系列操作，這些操作導致一個或多個業務對象，工作流和服務之間的交互。通過服務層，您可以將這些較小的交互與一箇中間API進行抽象，並通過更加粗糙的粒度服務進行展示。表示層對層中的一個服務進行一次調用。被調用的服務層方法將協調業務層中的對象和工作流以實現所需的行爲。
安全參與討論
如果你正在定義你的應用程序層，這些東西也需要關注。