從java中的域中分離用戶界面Swing

Question

作爲一個Java Swing新手，我在將用戶界面邏輯與域邏輯分開時遇到了一些麻煩。

我有一個JFrame包含JLabel，JTextField和JButton的小（平凡？）Swing應用程序。當按下JButton時，彈出一個JFileChooser對話框。選擇文件後，JTextField包含文件的絕對路徑。目前爲止沒有壯觀的景象。 我想完成的下一件事是，文件的絕對路徑被「注入」到文件管理器類中，該文件管理器類將在進行選擇並更新JTextField時處理文件的實際處理（每次文件是使用JButton進行選擇）。

問題，我有：

1. 如何讓文件管理器知道什麼時候開始讀文件？ （例如，計算該文件中的行數）
2. 如何以UI層內共享最少信息的方式實現域圖層？我應該添加一個文件管理器實例到用戶界面嗎？
3. 我應該使用JTextField的值作爲文件管理器的參考，還是應該使用JButton操作將值設置到文件管理器中？我的意思是：使用JTextField的propertychangelistener或使用JButton的actionlistener？
4. 我應該使用filebean來存儲域層中的文件的絕對路徑還是直接將其插入到文件管理器？區別在於：當我使用屬性更改偵聽器時，可以在UI輸入更改時更新絕對文件路徑的值，但是當我使用構造器或setter直接插入值時，必須處理文件管理器中的更改而不是處理filebean中的更改。
5. 如何在域邏輯中的文件管理器中引用用戶界面中使用的filebean？
6. 域邏輯是否與業務邏輯相同？我的意思是：文件管理器類應該在包中whatever.b邏輯和filebean類應該在包中的whatever.domain ??

應用程序被分成多個包：

• 什麼：主類
• whatever.presentation：搖擺的東西
• whatever.domain：數據的東西
• whatever.logic：應用邏輯

我希望我已經夠清楚了......

在此先感謝您的幫助。

Answer 1

就我個人而言，當我處理這些問題時，我會嘗試將可重用性和責任（誰負責什麼）視爲主要要求。

也就是說，我嘗試讓我的模型在這樣的情況下建立起來，以便他們不關心數據來自何處或來自何處，他們簡單地提供接口訪問來實現它。

要將所有元素連接到一起，我依賴於提供事件回到客戶端的模型，導致模型不應該關心誰想知道，只需提供所需的功能。所以，爲了向客戶提供反饋，我會依賴一系列聽衆。

我會將偵聽器分解成特定的作業，這樣的文件讀取通知將是它自己的偵聽器，對模型的更改（添加/刪除/更新）將是另一個。其他通知將需要不同的監聽器，這會阻止您創建實際上不想知道的怪物監聽器。

對於在模型中設置值，我會在屬性setter/getters方面犯錯。這將您的模型從實施中解耦出來（如果您以自動化方式使用模型，會怎麼樣？）

如果可能，內部數據將由模型進行最佳管理。也就是說，如果您更改模型正在管理的文件bean上的屬性，則該模型應該能夠監視更改並處理它。話雖如此，你可能會在將來的某個時候需要一個啞模型，在那裏你可以批量更新一系列文件bean，然後讓模型自行更新。

我個人可能會提供模型的外部更新方法，同時提供至少一個能夠提供自我監視的實現，這使您可以靈活地爲正確的情況選擇正確的模型。

這裏還有內存泄漏的危險。如果你不再需要從文件bean中刪除任何監聽器，那麼最終可能會阻止該bean在以後被垃圾收集。

儘可能使用接口。當試圖將這些模型放在一起時，這提供了很大的靈活性。

對於您所描述的內容，我會允許文件管理員負責文件管理器，以便文件管理器成爲文件管理器的容器。

取決於項目的規模以及您將來如何重用代碼將會極大地影響代碼的佈局。

我通常會將UI代碼放入UI包和子包中，但那只是我自己。我傾向於將界面內容與實現內容分開（通常物理上位於單獨的Jar文件中，但是，這就是我）。這意味着我只需要包含接口庫和我可能使用的實現，使用某種工廠來實際實例化實現（如果需要）（或直接按需要）。以JDBC驅動程序爲例。

你想看看領域的責任。從你描述的內容來看，我認爲文件bean屬於文件管理器的責任範圍，所以我將它們綁定在一起。

這只是我的觀點

Answer 2

點以下是一些建議：

• 使用SwingWorker所示here，以保證GUI熱鬧，一邊聽進步。

• 使用Action，圖示here來封裝功能。

• 使用File，一個方便的，跨平臺的抽象。用它來組成新的抽象，而不是拉出非跨平臺的作品。

附錄：又見A Swing Architecture Overview和answer。