本文主要記錄近兩天針對項目發生的資料通路問題的分析研究過程與系統架構優化，我喜歡說通俗的白話，高手輕拍
1. 發現問題
系統新子產品上線後，使用頻率較高，故在實際使用和後期的問題重制測試中，産生了一下系列的資料通路錯誤
錯誤是比較常見的錯誤
2. 分析問題
系統的架構為前端、業務層與資料層三層架構，采用entity framework 3.5作為資料處理技術，采用shared context per request模式，參照的是codeplex上的一個示例。（此文通俗易懂，代碼結構也很清晰，個人很喜歡）
entity模式的代碼如下：
基于以上，根據系統的報錯位置研究entity執行個體并發與共享的問題，搜尋了一些entity framework相關的資料。此問題主要從兩個角度去着手解決：縮短entity執行個體的存在時間和降低entity執行個體的共享性，并考慮性能，因為entity需要手動dispose。
首先添加手動dispose邏輯，我們的項目為sharepoint應用程式，是以和一般的.net略有不同。自行開發了一個basepage類，所有的應用程式頁面都繼承自該類，basepage類又繼承自layoutspagebase類，要做到使用完entity後及時dispose，最好也寫在頁面的類似結束請求的事件裡，于是在背景敲上protected空格override空格d->發現可重寫dispose方法，大喜，代碼如下：
修改之後部署，測試，發現報錯了：
the objectcontext instance has been disposed and can no longer be used for operations that require a connection
沒理由會這樣，因為每個請求都會執行個體化新的entity，不可能會被提前釋放。
調試代碼，斷點卡到第一段代碼get下面。重新開機服務，通路系統，附加程序開始調試，第一次get進來了，new了一個entity執行個體出去，頁面加載了出來；重新整理頁面，發現沒有再次中斷，到這裡，就非常的不合理了，肯定有忽視掉的地方，于是回過頭來一層一層檢視代碼，發現業務層和資料層的類都被寫成了單例模式，舉例如下
問題一定就在這裡了，将單例模式改掉，修改為如下結構
修改完後部署重複上述步驟調試，預期中的結果。
下周再和團隊一起系統地測試一遍，看看是不是有效果。
本來預期中的架構是沒什麼問題的，誰知當時又将操作類做成了單例模式而沒有引起重視，為目前錯誤的爆發埋下了伏筆。架構還是應該多推敲，多考慮的。
要下班了，是以寫的有些倉促；寫得看起來很簡單，但是研究的過程并不是特别簡單，都是耗費時間的。特此記錄。