我有一個winform,我有幾個選項卡上的一些控件。我正在編寫邏輯,它將基於用戶所做的組合框選擇來啓用/禁用這些控件中的一些。我猜測,在寫的frmMain.vb邏輯是不是最好的做法,所以我不知道我是否應該獲得通過訪問我的窗體的控件:通過frmMain朋友-聲明的屬性從類或接口更新表格
- 接口
- 的.vb由另一個類或訪問
- 其他
任何幫助將受到歡迎!
我有一個winform,我有幾個選項卡上的一些控件。我正在編寫邏輯,它將基於用戶所做的組合框選擇來啓用/禁用這些控件中的一些。我猜測,在寫的frmMain.vb邏輯是不是最好的做法,所以我不知道我是否應該獲得通過訪問我的窗體的控件:通過frmMain朋友-聲明的屬性從類或接口更新表格
任何幫助將受到歡迎!
通常,將前端代碼綁定到buisiness邏輯層是一個好主意,因此它是控制啓用/禁用控件的邏輯。如果可能的話,根據將禁用的內容對控件進行分組,然後製作一個一次禁用它們的例程,並將其命名爲或SetAddContactInfoArea(boolean isEnabled)
。在我看來,例程將在frmMain.vb
。 要避免的一件事就是將每個單獨的控件暴露給另一個類(除非在某些情況下,這是您需要的特定業務流程 - 但即使如此,您仍然應該將它放入例程中,並將其命名爲未來的編輯容易且不太複雜)。您的主要目標是管理複雜性(查看Steve McConnell的書Code complete,可能是第7章)。
一個理想的做法是對frmMain.vb
幾個public Sub
S,只有在那裏做什麼需要做了,那麼有商業邏輯層調用上的frmMain
的instace您正在使用的程序。
如果控件位於窗體上,並且用於隱藏和顯示它們的組合框也位於窗體上,那麼爲什麼在窗體上顯示/隱藏它們會是不好的做法?除非您正在處理在沒有用戶輸入的情況下檢索的業務邏輯,然後顯示或隱藏控件,否則無需將代碼從控件所在的表單移至另一個類或庫,從而使代碼進一步複雜化。我可以想到的另一個例子是,如果你想將顯示/隱藏代碼移動到一個新類中,那麼該類將在窗體上進行控制。 –