應該模型對象靈活

Question

[對不起，工作是私有的，因此我不能給對象的詳細信息]

我與同事的Java應用程序的工作。我正在做客戶端，他正在編寫服務器代碼。

該應用程序顯示一個X對象表。表中的列顯示X的一些屬性。另外，我們有一列顯示了每個X的Y數。（關聯是多對一的Y到X和一種方式，Y有一個對它的父X的引用）。

Y的計數不是X的屬性，而是通過DB上的查詢獲得的。

我正在使用TableModel，因此使用X對象作爲表格的模型顯然會更容易。但由於Y計數不是X的一個屬性，我需要創建一個容器對象來保存一個X和一個計數。這很煩人，因爲它增加了一個看起來沒有必要的類。

我建議我的同事說，他一個額外的字段添加到X加一個getter：

私人無效地圖信息=新的HashMap（）;

這將使模型對象X更加靈活。我可以隨時在客戶端存儲任何需要的狀態，而不影響模型的主要屬性，這些屬性是X的特性。只有在客戶端中定義密鑰才能保證模型不會受到污染。

他拒絕了，因爲他認爲模型對象應該只對域進行建模，並且額外的域與域對象無關，因此不應該添加。他認爲客戶應該處理這個問題。

這兩種觀點似乎都有優點，所以我會對其他讀者對此有何看法/感受感興趣。

感謝，

添

Answer 1

我想你混淆了在MVC模型的數據庫模型。請記住，MVC模式是表示層的設計模式。該模型即在MVC中可以是簡單應用中的數據庫模型（數據庫中的實體），但這不是必需的。

我認爲你應該有一個單獨的類（表模型），如你所說應該包含你在表中顯示的字段。該模型將從您的業務邏輯層填充，即應該是BLL的輸出。您也可以將其稱爲DTO（數據傳輸對象）。這個想法是隻有你需要的數據。如果您需要計數，那麼只需在DTO中計數，而不是全部Y.這不僅會使您的應用程序易於管理，而且還會減少數據傳輸，而不會影響層之間的數據傳輸，從而減少應用程序的內存佔用並提高表現也是如此。

Answer 2

我處於完全相同的位置（我主要是服務器端的人），我覺得它和你的同事一樣。

在我們的案例中，服務器端是一個Web服務。你永遠不會知道將來誰會調用這個服務，所以我想盡可能保持一般。無論何時我們需要模型中的特殊數據，我們都會擴展相應的類並以這種方式添加它們。通常情況下，這是毫無疑問的，因爲無論如何我們需要子類化（例如，我們需要在很多MVC類中使用PropertyChangeSupport）。

但是我不知道這是否解決了你的'數'例子。我們也遇到過類似的情況，我只是創建了一個特殊的DTO，因爲user446612表明保存數據。

Answer 3

謝謝你們的回覆。

Tingu說：

我認爲你是用模型混淆數據庫 模型MVC

好是肯定的。所以你在說客戶端應用程序中有兩個不同的模型對象，一個用於數據庫，另一個用於MVC中的M，而客戶端模型由BLL從檢索的數據庫模型對象填充？

musiKk通過我的閱讀說同樣的話。

我們在客戶端使用服務器端模型作爲數據模型（MVC M），對象很簡單。

musiKk給出了以下理由：

你永遠不知道誰將會要求在未來 服務，所以我想 保持儘可能通用。

這正是我的同事提出的論點。我完全同意這是至關重要的。但是我的想法是，在模型中添加一個對象映射並不會使模型不那麼一般。它爲客戶提供了方便，並且是一張空白的地圖。

的優點是：

（1）省去了用於一個簡單的例子是這樣創建子類或創建新對象與單個額外字段客戶端

（2）非常靈活的，因爲過渡狀態可以來與該對象封裝的，因爲它是在客戶機中使用

缺點是：

（1）對象是更大的通過網絡移動時這使得較大

（2）如果你子類你有額外的領域，即使你不使用它