應用程式框架實戰四你需要應用程式框架嗎

如果沒有什麼好處，不會有人願意去做，那麼，你真的需要應用程式框架嗎，它能為你帶來什麼好處？

現在來了乙個專案，你可以直接開啟vs，然後就開工敲**嗎？不行，你得先建立專案，當使用了分層架構，還需要建立更多的專案，這些專案根據依賴關係進行配置。然後依次引用各種依賴元件，很多元件還需要配置，比如log4.net。

配置好專案以後，你還得測試各依賴元件是否能正常工作，可能你的運氣比較好，一下就全部測試通過。但也有比較背的時候，半天調不通，這時候你會發現環境問題有時比**bug更難搞。

從頭開始建立和配置開發環境是勞神的工作，當你手頭有套自己的應用程式框架，情況就大不相同了，它為你提供了現成的開發環境。

隨著開源事業的發展，第三方開源框架名目繁多，層出不窮，另外第三方應用平台也多如牛毛。如果在應用程式中直接使用這些三方api，勢必被牢牢繫結，無法脫身，當要切換框架或應用平台時，不得不重寫應用程式**。

如果把第三方框架或應用平台api封裝到應用程式框架中，應用程式僅使用自己框架提供的api，這樣就可以輕鬆切換相關實現了。

當你的專案需求非常簡單，比如企業**，可能不需要什麼體系架構，建立乙個表現層專案，所有的**直接寫到介面上，或者後置**中。對於簡單專案，單層架構還是很有優勢的，簡單、快速。但更複雜的專案需要採用分層架構，目前普遍採用傳統三層架構或ddd分層架構。

特別是entity framework的普及，大家開始逐步採用ddd的一些設計元素進行構造。使用ddd的第一步是建立層超型別，即各層構造型別的基類。將層超型別放到應用程式框架中，而不是專案中，可以為多個專案提供支援。

前文提到，.net framework提供的是原始api,如果想在應用程式中訪問更易用的api,還需要自己動手，豐衣足食。

把常見的.net操作封裝到應用程式框架中，不僅在呼叫的時候更簡單，而且**得到集中管理，修改和擴充套件都更容易。

當採用分層架構以後，會發現開發工作量顯著增長，這是由於分層架構會建立多個專案，任何乙個操作，都需要在多個專案中建立**。另外體系架構越複雜，各層管道連線**也越多。

資訊系統最基本的操作是crud，手工建立這些**，不僅浪費時間，而且容易出錯。

通過應用程式框架配套的**生成器來生成這些crud和管道**，可以大力提公升開發效率。

大部分資訊系統都需要進行登入，主介面選單，許可權控制等操作，開發乙個完善的許可權管理模組需要數週時間。

在應用程式框架中內建一些通用模組，可以顯著提公升專案進度。

團隊開發的乙個問題是各程式設計師的程式設計習慣和風格不同，導致專案**異常混亂，沒人願意維護別人的**，當開發某一模組的程式設計師離職後，接手該模組的新程式設計師將痛苦不堪。

通過制定編碼規範可以一定程度改善這個問題，但還是非常被動，執行效果也可能不佳。

應用程式框架為團隊提供一套api，且基礎**由框架自動建立，編碼規範、程式設計風格得到強制實施，為後續維護奠定基礎。

綜上所述，量身打造一套符合自己習慣的應用程式框架，對專案質量、進度、可維護性等有重要意義。

應用程式框架實戰四 你需要應用程式框架嗎