ASP.NET——如何在不過度設計的情況下有效地使用設計模式！
自從 ASP.NET 出現以來，我很感激人們對我一直在努力解決的困境的想法。
在經典的 ASP 中，程式碼層很少。ASP 頁麵包含 HTML 和腳本組合。COM 組件包含業務邏輯和DAO基礎設施。ASP 頁面本身很亂，但一切都在一個地方。
ASP.NET 的程式碼隱藏整理了程式碼，這很好。這些控制項允許我們在表示層上更加物件導向。這些東西很好。
這是我的問題。我參與的許多項目都是企業 Web 應用程序，但並不是那麼複雜，比如 10 個左右的網頁/使用者界面、大量的數據庫互動等。這些過去理解起來是小菜一碟。現在我經常會遇到 5 到 10 層程式碼來創建一個相當簡單的網頁。這些可能包括 ASP、程式碼隱藏、控制類、DTO類、ORM 對象，然後是其他一些只是為了它而投入的。
除了訪問數據庫的 5-10 層之外，還有許多僅為儲存普通數據而創建的自定義對象，而不是使用諸如集合之類的POCO （普通舊 CLR 對象）。要理解這些對象，通常必須追溯包括 3 級或更多級別的對象和介面的繼承層次結構。
這裡是癥結所在：以前，我查看 1 個 ASP 頁面並說 1 或 2 個小對象，一些 SQL 查詢，這些都完成了工作並且維護和理解相當簡單。
現在，對於同一個頁面，實際上可能有 50 個或更多對象，分佈在自定義命名空間中的數百個對像中。
我問你們，程式碼工匠們，這是進步嗎？是不是有些人對他們的滑稽有趣的新設計圖案玩具有點過火了？有快樂的媒介嗎？ 有沒有一種方法可以有效地使用設計模式，而不會創建太多對象，以至於它變得比舊的程序範式更糟糕的意大利麵條程式碼？
請分享你的想法。
撇開組織需要這些抽象級別的可能性（不太可能，但確實會發生），開發人員（尤其是在非敏捷、公司/企業環境中）添加太多抽象層是很常見的。它發生在經典的 ASP 中，.NET 讓它變得更容易。我們大多數從事這個行業的人都有一種使事情過於復雜的自然傾向，而克服這一點需要紀律和積極的頭腦。
此外，許多平庸的開發人員錯誤地認為，最大化抽象層和模式使用會使他們成為更好的開發人員。
最後，許多平庸的開發人員被教導他們應該使用層、抽象和模式，但沒有被教導得足夠好，不知道如何、何時或為什麼。所以他們進入一個項目時會想“好吧，我知道我應該在這裡有一些層……”你可以想像會發生什麼。
最終，最佳實踐的“最佳實踐”是盡可能簡單地編寫程式碼，直到遇到阻礙您前進的真正問題。很多時候，您的工具箱中應該有適合該任務的模式或最佳實踐，就像您有合適的扳手扳手一樣。最佳實踐和模式是工具——你不會拿出錘子開始擺動，直到你有一個需要敲打的釘子。軟體開發也是如此。