編寫代碼的最佳方法是什麼？這是在Winforms中編寫代碼的最佳方法嗎？
（1）一樣直接編寫代碼在button_click()事件。
或
（2）請我寫button_click()事件，並在一個類中寫這個函數，然後那個函數我應該叫在button_Click() event.Like叫three-tier approach編寫代碼的功能代碼 ？
像button_Click()事件中，我寫的代碼保存記錄csv file from datatable。所以我應該寫代碼button_Click()事件或者我應該做一個新的功能和新的一個類，並編寫代碼在該函數在新並在button_Click()事件中調用該函數。
這只是一個例子，但我說的是我的應用程序寫的所有代碼，哪個是appropriate and best way to write the code，有什麼好處？請注意，我使用c＃在Winforms中編寫代碼。
你應該去單獨的功能在不同的班級。您應該這樣做，因爲您將使代碼可重用，並在用戶界面和應用程序邏輯之間創建一個體面的分隔。像這樣，你可以在不影響應用程序的其他部分的情況下更改UI。
而且看看MVC pattern，你會更好地理解這個念頭。
我認爲應該使用第一個選項的唯一情況是當它執行一些會影響UI的操作時，我仍然會在Form類的一個單獨函數中創建它。
如果它影響UI，它應該在同一個類中，因爲它是相關的，例如它是一個刷新網格的代碼，我會將它放在同一Form類中的一個單獨的方法中，因爲可以使用它在裏面的不同地方。所以改變用戶界面對應用程序沒有影響，你只需要讓你的代碼可重用&就可以維護。
@Adrian Faciu，當需要改變UI對應用程序的其他部分的影響時，請澄清。 – Harikrishna 2010-05-06 05:38:44
@Harikrishna我編輯了我的文章，我希望現在更清楚。 – 2010-05-06 06:06:16
這一切都取決於情況。
如果你要進行更新的形式，則最好是在窗體的更新代碼。但是，如果有很多處理，那麼確實有更好的設計來讓一個單獨的類來處理這個工作。
這一切都取決於情況。
一般情況下，你不希望在事件處理程序的任何邏輯，因爲圖形用戶界面往往會觸發相同的命令提供冗餘機制（上下文菜單，菜單欄，工具欄，快捷鍵），以及事件簽名不是兼容所有這些。然後問題就變成你的通用函數應該放在Form類還是數據模型中。
我常常在開始時表中提供的邏輯，然後根據需要它重構爲模型類。許多小應用程序永遠不會變得足夠大，以至於可維護性需要多個類。只要你避免代碼重複（即複製+粘貼），那麼如果你覺得你需要它，重構將會很簡單。
開發職位類總是很好的。因爲它使您的代碼可重用，並且它還實現三層體系結構。好處是它很容易理解。
重要的是，只有適當地開發你的課程纔是有益的。在課堂上開發可以重複使用的方法。
另一個好處是它隱藏了代碼的複雜性。
對不起，但我不知道。只需在互聯網上搜索...你可以得到很多有用的信息。 – Himadri 2010-05-06 06:33:02
將結構添加到代碼有兩種常用方法：自上而下和自下而上。自頂向下的結構來自設計工作，可能涉及正式或非正式流程以及純粹的設計工件，如UML圖或功能規範。自頂向下過程的最終目標是在代碼中創建類和接口，以提供適當的結構以使代碼可維護。這可能在您編寫代碼之前發生，或者作爲迭代的一部分發生，但想法是您先創建結構，然後創建代碼。
自底向上結構來自重構。例如，從點擊按鈕開始你的所有邏輯。當您添加與按鈕單擊操作相同的菜單項時，將您的按鈕單擊功能的代碼移動到窗體上的私有成員函數中。當你在應用程序的不同部分需要相同的功能時，將私有成員函數使用的代碼和狀態變量封裝到一個類中。
我推薦使用這兩種方法。您的情況的正確組合取決於開發團隊（大小，位置，溝通能力）和應用程序的大小。一般來說，大型應用程序需要更多的自上而下，而對於非常小的應用程序，最少量的自上而下設計就足夠了。但是，即使是一個小應用程序，也應該有一些高層次的規劃。
請注意，解耦模型和視圖並不意味着您只需從事件處理程序方法提取代碼，並在其他地方放置完全相同的代碼。額外的調用不會突然使其成爲「MVC」甚至「三層」（儘管後者實際上是關於不同的事情）。你需要做的是將你所指定的功能模型化爲模型類 - 從_model_透視圖和麪向對象的設計中有意義的方式 - 然後根據需要使用你的事件處理器中的那個功能。 – 2010-05-06 06:10:16
還可以看看數據綁定，INotifyPropertyChanged和IBindingList BindingList。通常，在你的模型類上實現的那些組合以及通過綁定連接到用戶界面的組合無需編寫事件處理程序。 –
2010-05-06 06:10:52