班級數據責任

我有一個'採購訂單'類。它包含有關單個採購訂單的信息。我有一個數據庫方法的DAO類。班級數據責任

責任在哪裏應該加載和更新採購訂單的方法？

如果PurchaseOrder類具有直接使用DAO類的'.update'，'insert'，'delete'和'.load'方法，或者PurchaseOrder類不知道DAO方法並且有POController管理這些交互的類？

用戶一次只能在一個PurchaseOrder上工作。

謝謝！

來源

2008-10-03 GernBlandston

採購訂單應該不知道其持久性的細節。這是具有某種數據訪問層的一點，它處理對象的管理，並且對象本身可以專注於僅僅是購買訂單。

這也使得系統更容易測試，因爲您可以創建模擬採購訂單並測試系統如何處理它們的邏輯，而不會糾纏於持久性問題。

來源

2008-10-03 15:13:04

-1

我肯定會從數據庫交互/訪問中分離出「業務邏輯」（PurchaseOrder）。如果您轉移到不同的供應商等，您將更容易地對訪問進行更改，而不會干擾業務實施，並且您可以更輕鬆地避免向數據庫訪問層添加行爲。

來源

2008-10-03 15:12:51

-1

就我個人而言，我會創建一個管理交互的對象。我不能把這個邏輯放在PurchaseOrder類中，但是創建這個控制器對象會導致更鬆散耦合的對象。

來源

2008-10-03 15:16:16 SpooneyDinosaur

這取決於您認爲您的應用程序將存在多久。我公司的金屬切削應用自1985年以來一直在不斷髮展，並已通過計算機體系結構的多重變化而取得了進展。在我們的例子中，我們幾乎總是將事情推到一個界面（或者控制器類使用你的術語）後面，因爲我們不會處於5,10,15年後的狀態。

通過使用控制器類，我們可以更改底層API，而不會篡改上面的業務邏輯和UI調整級別。這些水平代表了多年的工作，所以保持他們的行爲很重要。

記住你的項目將在維護中的大部分時間。您現在做的任何事情都可以讓以後更改設計變得更加容易，這將爲您節省大量時間。

來源

2008-10-03 15:17:05

PurchaseOrder類應該不知道DAO。 purchaseOrder類應該代表數據本身，僅此而已。使用控制器或服務管理器或任何你想調用它來使用DAO持久/加載PurchaseOrder記錄。這使您在設計中擁有最大的靈活性。您有一個地方爲您的數據模型，一個地方爲您的業務邏輯（控制器）的PurchaseOrders如何存儲/檢索和一個地方，其實際上堅持。

來源

2008-10-03 15:20:09 IaCoder

-1

在這裏考慮的關鍵是你可能想在未來做什麼。也許你想用另一個替換你的數據庫？這就是爲什麼你一定要將你的代碼與表示PO的類中的數據庫進行交互。這是責任的基本分離，我希望你已經做到了。

現在的問題是：你是否想要第三類（控制器）來管理PO和DAO類之間的交互？我認爲這取決於你可以如何使DAO類的接口。如果DAO接口足夠普遍，您可以使用不同的存儲機制爲它編寫插件替換，但不更改接口，那麼我會讓PO類與它交互。如果沒有，那麼我會寫一個控制器類。

另一件要思考的是結構的其餘部分。保存/加載從哪裏開始？如果您要對PO進行大量操作（保存，加載，打印，發送給客戶），那麼讓控制器執行所有這些操作而不是將功能集成到PO類中是有意義的。它爲您提供了可以添加採購訂單操作而無需修改採購訂單類的優勢。

來源

2008-10-03 15:22:43 DJClayworth

我通過將PurchaseOrder作爲接口並將所有DAO代碼放入實現中，然後使用工廠來保持簡單。

來源

2008-10-03 15:42:08 shyam

讓我帶你通過我的推理：

類方法
基本原則：持久性是一個類的行爲，應該是一個類的方法
你需要關注點分離，所以你把數據庫在DAO類中的本質，並使用類來實現這些方法。
第一個問題：如果您需要支持不同的DAO套件，則需要通過工廠創建它們。第二個問題：並非所有的持久性行爲都與該類的實例特別相關。例如List和Search方法：它們返回Class列表，而不是類，並且不依賴於實例。所以他們基本上是靜態方法。
第三個問題：你想支持這個類的繼承。因此，持續細節因父母之間而異。如果你有靜態方法，這將是一個問題。

所以你移動到

控制器
基本原則：持久性方法不屬於一個類，它們更大，因此它們應該分開需要
的關注點分離再次，所以你需要DAO。這是一個Utility類，所以方法基本都是static。
第一個問題：如果您想要支持多種持久性方法，則需要工廠來創建DAO。
第二個問題：你想支持一個Classes層次結構，所以你不能使用靜態類。您需要通過工廠生成控制器。
第三個問題：您向開發人員提供過於複雜的API。的客戶端代碼
示例：

PurchaseOrder po; 
PurchaseOrderController poc; 
poc = PurchaseOrderControllerFactory.Instance.Create(); 
po = poc.GetPurchaseOrder(42); 
// do stuff 
poc.SavePurchaseOrder(po);

然後我會從頭開始。

從行爲開始
基本原理：持久性不是一個行爲。行爲比持久性更大。
在您的系統中將會有一個採購訂單子系統。您的用戶只能在高級別（用例級別）才能與之交互。所以，這些方法將實現採購訂單用例。這些方法將使用DAO，如果需要，通過工廠訪問數據庫並執行他們需要的任何操作。
總之，您的PurchaseOrder基本上是一個DTO，一種快速傳遞數據的方法。它不應該有行爲。
客戶端代碼示例：

// It could be a factory if needed. 
PurchaseOrderSystem pos = new PurchaseOrderSystem(); 

List<PurchaseOrder> transacted; 
transacted = pos.TransactPurchaseOrders(john, 23); 

// Show transacted purchase orders or whatever...

來源

2008-10-03 16:24:32 Sklivvz

班級數據責任

回答

相關問題