戰略建議：升級Web應用程序的設計

Question

我有一個專門用於報告PBX擴展統計信息的ASP.NET網站。它包含許多報告頁面，使用幾乎完全由代碼隱藏（設置Label控件的Text屬性而不是使用Response.Write）生成的HTML，使用未參數化的字符串文字SQL查詢來填充「參考數據表」參數。

維護頁面至少包含DataGrid和詳細信息表單，但在e上使用相同的DAL，因爲可以說它支持多個DB服務器，每個子類都使用它們自己的字符串重寫這些訪問方法查詢。

我需要考慮清理這個爛攤子？我已經做出了一個幾乎明顯的決定，即使用第三方報表解決方案，並將查詢移動到各自的數據庫語言中存儲的特效庫，縮小不同DAL類的多樣性，並將CSS分成共享文件它非常隱藏在C＃文件中！

Answer 1

我會考慮拋棄任何自定義編寫DAL和使用的一個：

• iBATIS.NET
• NHibernate
• SubSonic

你甚至可能最終下探存儲過程完全。

如果你敢於嘗試使用Microsoft's MVC實現進行重新設計。無論採取什麼方法，都要確保在重構​​任何代碼之前編寫單元測試，驗證測試在重構之前和之後通過。

Answer 2

對於您的後端設計，我建議您有一個類來表示數據庫的每個主表（例如，Report類和User類）。任何不是事件處理程序的東西都應該放在後端類文件/命名空間中。

對於你的GUI，看起來你正在使用ASP.NET控件的正確軌道，而不是將數據流式傳輸給用戶。但是，您可以考慮客觀化頁面的區域。例如，我最喜歡的技巧之一是在顯示短消息時需要用戶輸入或類似信息欄時打開半透明的「彈出」面板。

考慮AJAX和AJAX控件工具包。這很容易實現（特別是在重寫的情況下）並且提供了很大的靈活性。具體來說，我發現手風琴 - 有時甚至嵌套在其他手風琴中 - 在組織過多信息方面非常出色。

編輯：

請注意，如果你使用AJAX，你基本上甚至不能考慮使用的Response.Write了。

只要屏幕上的內容太多，請記住面板具有「滾動條」屬性，並且DIV不會發生重大更改。

另外，我傾向於用命名空間來分隔我的代碼文件;但流行的趨勢是由班級這樣做。如果您有許多開發人員，或者可能會有多個名稱空間中的類被檢出或由不同的人同時修改，則這是更好的選擇。