我正在構建一個MVC Web應用程序（使用Spring MVC框架），並且我對設計特定區域的最佳方式有點難以理解。當業務邏輯和數據層看起來重疊時，最好的設計是打破業務邏輯和數據層？
應用程序必須通過一系列的網絡服務，這是不是真的，大大設計的，本身並沒有提供太多的抽象交互 - 基本上有一個Web服務方法，爲每個創建/更新/檢索/刪除每個「數據類型」的操作，除此之外沒有太多的API。 Web服務客戶端需要知道要調用哪些方法以及以何種順序創建所需的數據 - 換句話說，不存在基於「事務」的方法。例如，簡單地創建一個新的用戶帳戶需要調用總共七種不同的Web服務方法來設置必要表中的所有記錄（一個user記錄，將正確的privileges添加到該用戶，設置用戶的billing細節等）。
我在用最好的方式來抽象並封裝在我們的應用程序中掙扎。大多數應用程序都遵循一個標準流程：
request ---> Controller <---> Service/Business-level object <---> DAOs for data access
在我的申請，我用我自己的一套在Web服務WSDL定義的「域對象」來表示和抽象數據類型的，所以，我的領域邏輯不依賴於Web服務類型，因此我們可以抽象和隱藏我們喜歡的任何細節。
我正在尋找一些意見是設計「用戶創建過程」的最佳方法，我以上提到的爲例。正如我所提到的，創建「普通用戶」的過程涉及調用七種不同的Web服務，但這只是一種「類型」用戶 - 我們必須能夠創建幾種不同類型的用戶，每種用戶需要不同的用戶Web服務被調用。
目前我只設計了這個「普通用戶」的創作，作爲一個位概念證明的 - 我有一個域對象User，一個UserDao接口，具有getUser(name)和createUser(User)方法，並實現了一個WebServiceUserDaoUserDao方法，並知道如何調用上述七種Web服務方法。 createUser()方法由UserCreationService調用，這是我的業務/服務級別類別，然後由SignupController調用。
但是爲了擴展這個邏輯以便能夠創建不同的用戶類型（在User.getType()中用不同的值表示，我不確定在哪裏繪製業務/服務層類和DAO之間的界限。舉例來說，我應該：
- 創建每個「用戶類型」一和
UserDao實施，使創建每個「用戶類型」可以在它自己的類來封裝，並讓UserCreationService決定使用哪個UserDao的邏輯是什麼？這將對應於1個服務級別：許多DAO。 - 我應該打破
UserDao分成較小的部分，即使我的整體應用程序不需要知道每種類型的單個類型，其中一個對應於需要在Web服務/數據庫中創建的每個「記錄」？然後針對各種不同的「用戶類型」有不同的UserCreationService實現？換句話說，即使我不需要對應的域對象PrivilegesDao，BillingPlanDao等，這種策略也會有。這將是許多服務類別：許多DAO。 - 包含所有需要針對每個「用戶類型」在一個
WebServiceUserDao中調用Web服務的邏輯？這將會帶來類似非常複雜的缺陷（PMD已經在抱怨圈複雜度），但是所有這些邏輯都會被封裝在一個類中，並且從整體API的角度來看可能會導致更少的複雜性。
我對這個應用程序的一個目標是確保如果我們必須改變數據持久性的細節，那麼我們需要做的就是改變DAO實現 - 如果我們必須啓動接口使用不同的計費系統，我不希望應用程序的任何部分在DAO級別以外進行更改。
有沒有意見？當決定將「業務邏輯」與「數據訪問邏輯」看似重疊時，如何劃分「什麼樣的策略」？
正面，間接，+1 – annakata 2009-01-28 15:04:25