設計用於2版數據模式的Web界面

Question

我正在設計可支持2個或更多數據模式版本的Web界面。以JAVA表示的數據模式可能看起來像

PersonV1 { 
    String fname 
} 

PersonV2 { 
    String fname 
    String lname 
    String email 
} 

在未來，我期待新版本被添加。是否有任何有關如何根據DRY原則構建此類用戶界面的最佳做法等。

有關此的一點背景知識。我們有一個產品A，並且對於該產品的每個版本，我們可能有不同的模式。因此，每個實例版本都創建一個新的模式。然後這個模式通過jaxb被製作成一堆Java對象並存儲爲一個庫。每次有新版本的產品A時重複此過程。

產品B將利用該庫並從產品A中獲取xml，因爲我們知道它來自哪個版本，因此我們將能夠填充正確的對象，並將其用作UI的意義上的域對象。

謝謝

Answer 1

根據您的web界面的客戶類型多樣，你可以去兩條路線：

1. 添加模式版本信息的路徑或在每個對象。然後，每個客戶端都必須將特定模式版本的對象轉換爲可以使用的表單。對於比客戶端軟件更新的版本，最安全的方法可能是完全拒絕它。

2. 有客戶在他們對服務器的請求中指出他們的首選/唯一接受的模式版本。然後由服務器決定將其當前模式轉換爲客戶端請求的模式，還是使用400來指示不能支持所請求的模式。

因此，可以說你有一個只關心fname的web客戶端。在接收Person時，不管模式版本如何，它都會提取fname並繼續。

比方說，另一個網絡客戶端需要的電子郵件地址。它會接受一個v2個人物件，但如果它返回一個v1人物，則通知用戶該服務器不兼容。

最後，讓我們假設v3用名稱替換fname和lname。在這種情況下，v2可以通過附加fname和lname轉換爲v3，也許v3可以通過在空間上拆分名稱來轉換爲v1，但是從v1到v3可能很難做到有意義的事情。

顯然會有很多情況下，客戶端或服務器必須放棄，並簡單地報告服務或客戶端不兼容。但是，由於您是從頭開始設計服務的，因此希望您對模式更改進行更多的思考和謹慎。

有很多流行的文件格式標準與這類問題糾纏在一起。例如，Zip文件格式有多個修訂版本。生產者和消費者都必須制定一個如何處理特定版本文件格式的策略。 Java二進制類格式是另一個例子。