我正在構建一個MVC Web應用程序(使用

Spring MVC框架),我對設計特定區域的最佳方法感到有些困惑.

應用程序必須與一系列Web服務進行交互,這些Web服務并非真正設計得非常完美,并且本身并不提供很多抽象 – 基本上每個創建/更新/檢索/刪除操作都有一個Web服務方法.每個“數據類型”,除此之外沒有太多的API. Web服務客戶端需要知道要調用哪些方法,以及能夠以何種順序創建所需的數據 – 換句話說,沒有基于“事務”的方法.

例如,只需創建一個新的用戶帳戶,就需要調用總共七種不同的Web服務方法來設置必要表中的所有記錄(用戶記錄,為該用戶添加正確的權限,設置用戶的帳單明細等).

我正在努力用最好的方法來抽象它并將其封裝在我們的應用程序中.大多數應用程序遵循標準流程：

request ---> Controller Service/Business-level object DAOs for data access

在我的應用程序中,我使用自己的一組“域對象”來表示和抽象Web服務WSDL中定義的數據類型,這樣我的域邏輯就不依賴于Web服務類型,因此我們可以抽象和隱藏我們喜歡哪個細節.

我正在尋找一些意見是設計上面提到的“用戶創建過程”的最佳方法.創建“常規用戶”的過程涉及調用七種不同的Web服務,如我所提到的,但這只是用戶的一種“類型” – 我們必須能夠創建幾種不同類型的用戶,每種用戶需要不同的要調用的Web服務.

目前我只是設計了這個“常規用戶”創建,作為一個概念證明 – 我有一個域對象User,一個UserDao接口,它有getUser(name)和createUser(User)的方法,以及一個WebServiceUserDao,實現UserDao方法并知道如何調用上述七種Web服務方法. createUser()方法由UserCreationService調用,UserCreationService是我的業務/服務級別類,而后者又由SignupController調用.

但是要擴展此邏輯以便能夠創建不同的用戶類型(由User.getType()中的不同值表示,我不確定在業務/服務層類和DAO之間繪制線的位置.例如,我應該：

>為每個“用戶類型”創建一個UserDao實現,因此創建每個“用戶類型”的邏輯可以封裝在它自己的類中,讓UserCreationService決定使用哪個UserDao？這將對應于1個服務類：許多DAO.

>我是否應該將UserDao分成更小的部分,一個對應于需要在Web服務/數據庫中創建的每個“記錄”,即使我的整個應用程序不需要知道這些個別類型中的每一個？然后為各種不同的“用戶類型”提供不同的UserCreationService實現？換句話說,即使我不需要相應的Privilege或BillingPlan域對象,此策略也會有PrivilegesDao,BillingPlanDao等.這將是許多服務類：許多DAO.

>包含在單個WebServiceUserDao中為每個“用戶類型”調用Web服務的所有邏輯？這將具有非常復雜的缺點

class(并且PMD已經在抱怨圈復雜度),但所有這些邏輯都將封裝在一個類中,從整體API角度來看,可能會減少復雜性.

我對此應用程序的一個目標是確保如果我們必須更改數據持久性的詳細信息,我們需要做的就是更改DAO實現 – 如果我們必須開始與不同的計費系統連接,我不希望應用程序的任何部分在DAO級別之外進行更改.

任何意見？在決定何時分解“業務邏輯”與“數據訪問邏輯”時,您使用什么樣的策略？

總結

以上是生活随笔為你收集整理的java业务层怎么设计_java – 在业务逻辑和数据层看起来重叠时分解它们的最佳设计？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。