在我們的項目架構中，數據庫訪問通常是用entity framework（EF），另外有一個很重要的service層，主要用於跟EF交互，也會在這一層封裝大部分的業務邏輯。通常情況下，我們會用一個接口將某個service的成員提出來，然后通過IOC獲取該service的實現。
由於service層主要為UI層提供服務，為了讓調用者直接的看到可用的方法，因此往往某個service會包含某個模塊的所有方法和屬性，於是這個service會變得非常龐大。舉個例子，比如我們有一個IProductService，用於為product模塊提供數據服務。這個product模塊下面包含多個子模塊，比如該product的各種統計數據，銷售，訂單，跟蹤信息等。這樣一來，這個IProductService下面就可能有30多個方法，如果將這么多的方法寫到一個文件里頭，那這個文件很難不超過300行代碼。
讀到這里，你肯定在想我們可以把這些實現的代碼分成多個塊。可能首先想到的，也是我們大多數程序員正在寫的，那就是#region/#endregion。 其實還有另外一個方案，那就是partial class。
使用partial class來拆分我們的service，其實只是一個太簡單不過的想法，但就是這個思想上簡單的進步，拯救了我多少的代碼。從此，我的service類非常豐富，而service的實現根據模塊或者調用者角色或者其他分配到多個partial類，每一個文件不超過300行代碼，讓維護變得非常簡單，讓代碼變得易讀。
其實使用partial類來拆分我們的大類不僅僅是可以用於service層，而是可以用於任何地方。
我最近新加入了一個項目組，這個項目的代碼寫的有些糟糕，很多類超過1000行代碼，很多方法200多行代碼，看到這樣的代碼實在不想去打開編輯，更別談讀懂其業務邏輯並維護。這個項目運行了好幾年了，好幾批程序員寫過代碼，可以說這個項目被多少程序員糟蹋得不成樣子了。經過簡單的分析，其實主要的問題在於service層和controller層的類文件太大，於是我安排人員用partial class進行拆分。重構后的代碼別提變得多清純了，讓我們這些IT男喜歡不已。
朋友，你的項目里有大類嗎？試着用partial class拆分下吧，相信你會有驚喜的。