技術架構：服務層還是沒有？

Question

我們有一個由少量應用程序組成的平台。

我們必須開發一個API，該API必須將與數據庫的所有交互都分解為因素。 在此API中，我們還將擁有XML格式的數據庫版本。 XML格式將僅由一個應用程序使用。

我們的應用程序是在經典的體系結構中開發的：dao-服務層-表示層。

DAO層將移入API。 在這一點上沒有問題。 在許多應用程序中，服務層只是表示層和導引層之間的網關，而沒有特定的業務代碼。

所以我的問題是：

• 我們是否應該為每個dao創建一個帶有Service層的API？
• 如果是，那么在應用程序中保留一個服務層，該服務層從API調用服務層？
• 我們是否應該在API中創建一個用於管理工廠（數據庫/ XML）的服務層，但這意味着每個應用程序都必須提供信息以選擇要選擇的dao（當只有一個應用程序有此需要時）？
• 還是僅在API中的數據庫和xml的不同包中創建所有dao，將工廠保留在有需要的應用程序中，然后在所有其他應用中調用dao（數據庫）？

需要幫忙 ！ ：p我迷路了...

僅供參考，我們在Java 1.6和Spring 3.1.1中。 DAO中的JDBC模板暫時。 我們正在尋找有關Spring數據jdbc的信息，以替換JDBC模板。 對此的任何建議都值得贊賞^^ [No Hibernate-JPA solution]

謝謝。

---

[編輯1]

換句話說，在應用程序和API中保留服務層是我擁有抽象層的一種方式。 如果我們必須修改數據庫結構，那么如果我們也可以直接在API的服務層中進行一些更改，那么也許不必編輯所有應用程序。

想象3種可能性：

1. 具有工廠的API中的服務層，以選擇要使用的dao（xml /數據庫）
2. 只是在API中
3. 數據庫API的服務層和XML API的特定層

您選擇什么解決方案？

[編輯2]

創建一個唯一的類來調用API有趣嗎？ 就像在立面設計模式中一樣。

Answer 1

使用服務層實現目的：通過提供的每項服務使用一個或多個DAO來提供真實的服務（以及其他諸如管理事務，清理String等之類的東西）。

如果您（與經驗豐富的同事一起）認為您不需要此服務層，則不要將其放入體系結構中。 但是請確保創建您的體系結構的概念證明（其中可能包含系統或部分系統的某種復雜功能的實現），以便稍后進行評估以證明您是否真的不需要這種層（或如果您這樣做）。

Answer 2

我的理解是，您需要使業務層與表示層脫鈎並重用，使多個客戶端應用程序使用同一業務實現。

在這種情況下，您需要在API中實現服務層。 一些優點：

1. 您無需為任何處理演示的客戶端應用程序重復執行服務。
2. 您可以輕松地將數據庫模型設計與業務脫鈎。 設計模式（DTO，Facade）和橫切關注點可以很容易地引入。
3. 與擁有數據庫實現細節的DAO相比，設計良好的服務層將需要最少的修改。

在此API中，我們還將擁有XML格式的數據庫版本。 XML格式將僅由一個應用程序使用。

通過API提供此實現，如果需要，將來更多的客戶端應用程序將能夠使用它。

Spring遠程處理為此類設計提供了出色的工具（RMI，HTTP調用程序等）

在證明DAO的API方面，我沒有看到任何附加價值。