串行終端應用程序的設計模式

我作爲內部串行終端應用程序的單個開發人員工作。我的目標是編寫一個框架，具有足夠的靈活性，我可以用它來創建三個獨立的應用程序：串行終端應用程序的設計模式

串行終端應用程序（很像超級終端）
數據分析中的應用（將整理並顯示根據串行數據一定的標準）
解碼應用（將處理串行數據，並從數據庫中顯示相關信息）

在未來的某個時刻，我想這三個應用程序合併爲一個。但是，這遠非優先事項。我已經將框架分成三個獨立的部分 - GUI（視圖接口），後端（控制器接口）和設置處理程序（ISettingsHandler接口）。但是，我已經遇到了一些循環依賴問題（ISettingsView必須移動到與ISettingsHandler相同的命名空間），表明了更多的麻煩。是

我的針對每個應用的要求如下：

串行終端 - GUI必須能夠將數據傳輸到和從串行端口，顯示和修改設置，和發送文件
串行分析應用 - 界面必須能夠檢索收到的串行數據，並顯示和修改設置
解碼應用 - GUI必須能夠檢索輸入的串行數據

我是否比這應該是更復雜？我知道我可以用更少的接口完成同樣的事情，但我擔心這個框架的靈活性，以備將來使用。有沒有適合這種情況的設計模式？

Current pattern diagram

編輯：爲了澄清，每個框架的三個「片」的是在不同的命名空間。

我已經修復了循環依賴，但是，我仍然不確定這是否是此應用程序的最佳設計模式。任何建議？

來源

2011-02-01 CWMan

命名空間是邏輯分隔符和一種組織類的方法。你如何組織他們取決於你。如果它們不相關，我不會將它們放入同一個命名空間。 – 2011-02-01 17:12:53

之一的設計原則是「好萊塢原則」，規定「你不打電話，我們會打電話給你」（從頭部首先設計模式）

循環依賴是一個常見的問題。爲了避免它遵循這個原則。

請勿在較低層中引用較高層接口/類。高層類應該使用低層接口/類。

例如，ISettingsHandler應該引用IController而不是其他方式。即使你正在實施具體的課程，也要遵循這個原則。

您的代碼將更易於維護。

來源

2011-02-03 05:45:03

如果您正在運行循環依賴項，則需要將共享資源提取到不同的項目中（例如：將所有接口放入MyProject.Contracts項目中）。然而，如果你遵循適當的分層，你不應該有這些問題。

來源

2011-02-01 16:43:14

我應該將所有接口放在同一個命名空間嗎？我的印象是，它們應該放在相同的命名空間中，因爲從它們派生的類將被放置。 – CWMan 2011-02-01 16:59:32

接口與類無關。接口是任何人都可以實現的契約，所以它們不需要在同一個名稱空間中。如果你有全部三層引用一個接口，你需要將它提取到一個沒有引用任何其他項目的共享項目中。這就是你解決循環問題的方法。你如何組織他們取決於你。 – 2011-02-01 17:03:04

在這裏，您可以使用基於opon好萊塢principale的接口依賴注入

來源

2011-06-09 11:29:56 Kamahire

串行終端應用程序的設計模式

回答

相關問題