2012-11-22 57 views
0

我不確定最佳實踐是什麼。
我有一些大而複雜的物體(不平坦)。
在這個對象中,我有很多相關的對象 - 例如發票是主類,其中一個屬性是invoiceSupervisor - 它自己稱爲User的一個大類。
用戶也可以不平坦,並有部門屬性 - 也稱爲部門的對象。在客戶端或服務器端更改對象

例如,我想創建新的發票。

第一種方式:
我可以向客戶展示幾個領域來填補。其中一些將是我需要填充可用值的組合。例如可用的發票管理員。然後,我可以將所有選定的值發送到服務器,並在服務器上創建新的發票並將所有選定的值分配給新的發票。然後,我將需要分配新的主管,我將通過組合框從用戶在服務器上獲取的ID拉選定的用戶。我可能會對用戶進行一些驗證,例如用戶是否適用於發票主管。然後我將User對象分配給invoiceSupervisor。然後填寫所有屬性後,我將保存新的發票。

第二種方式:
在開始時我可以打電話給服務器以獲取新的發票。然後在客戶端上,我可以填寫所有選擇的值,例如我可以調用服務器來獲取新的用戶對象,然後從組合框填充它的ID並將用戶分配爲invoiceSupervisor。在客戶端填寫發票對象後,我可以將其發送給服務器,然後服務器將保存新的發票。在保存服務器之前,也可以運行一些驗證。

那麼什麼是最好的方法 - 在客戶端上創建對象並將其發送到服務器或從客戶端收集所有值並在服務器上使用這些值創建新對象?

回答

1

根據業務處理的複雜性來考慮。

你需要的是客戶創建一個新的發票。爲此,客戶端提供了幾個不同的輸入參數,調用過程並獲得響應。這是你的第一個場景。簡單明瞭。另一方面,第二種方法涉及通信協議 - 給我這個,我給你一些東西作爲迴應,然後給我一些其他的東西。這聽起來不合理地複雜。您必須仔細檢查通信在某個時間點發生什麼情況。是否應該涉及分佈式事務?如果是的話,你真的需要這樣的複雜性嗎?

我會選擇然後第一個場景。您不會不必要地使客戶端和服務器之間的合同複雜化。

+0

我傾向於同意你的看法。在我的公司裏,有關於這個問題的一些辯論。那些喜歡第二種方式的人聲稱這種方式「更清潔」。在第二種選擇中,客戶端和服務器之間的一個大對象正在與幾個對象進行轉移 - 如果選擇第一種方式,有時需要將10-15個值從客戶端傳輸到服務器。 –

相關問題