一眨眼一年就過去了，去年參加鐵人賽的心情彷如昨日。
經過一年的時間，終於又回來專注於開發我比較習慣的環境，也就是Asp .Net Mvc。
因此相較於去年的主題“C# Web 開發 跳到 Java Web開發”，今年的主題“以Asp .Net MVC 5 為基礎，建立自己的程式開發框架”難度比去年高，同時也是一直以來我想要做的事情。
希望今年也能夠帶給大家一些幫助。
爲什麽要寫這個主題？
在用Asp .net Mvc開發不同的專案過程當中，我漸漸的發現，其實有些東西寫起來真的很枯燥（因為都是一樣的東西），並且是很容易被漏掉。尤其是當和別的開發者在共同開發的時候， 雙方的認知不同，寫出來的東西就會有差異。
舉例來說，當Server接受到 Client的Request，做了一些處理，處理完了，要返回View並且顯示一些回饋訊息給使用著的時候，如果沒有一個共通的方法，每一個人的寫法都會不一樣。
開發者A或許會用ViewBag作為訊息的載體，而開發者B則會用TempData。而在顯示方面2個人也許也會不一樣，開發者A或許用簡單的alert而開發者B或許會用其他第三方插件。
或許定義一個開發文件的話可以減少上面提到的問題，但是在實務上面，很難同時讓文件和開發習慣同步。換句話說，在專案啟動的時候或許大家還能夠遵守，但是 漸漸的，就沒有人去看開發文件或者更新開發文件的內容以符合目前的開發習慣。
那麼怎麼解決這個問題呢（或者減少這種問題）？如何讓開發團隊（或者就算開發著只有自己）能夠不在關注於那些很繁瑣但是又重要的細節的情況下， 又不會漏掉這些必做的小細節呢？答案就是建立一個適合團隊（或者自己）的開發框架（Framework）
什麽是框架（Framework）？
當我們把一些常用的功能抽出來，它就變成了一個library或者通用行的Utility Method。例如，一個發送email的library，或者一個用來寫log的library。
當我們把這些library組裝起來，讓他們能夠各司其職又能夠無縫使用，並且想要客制的時候就能夠客制，這就是框架。
換句話說，以樂高的角度來看，library就是每一塊的積木，堆疊出來就是框架。那和樂高一樣，最後疊出來的東西是最符合你的需求和環境使用。
框架還有一個很重要的特性就是Mvc常說的：Convention Over Configuration （習慣取代設定）
最典型的就是Mvc裡面的Return View()。在不給任何view name的情況下，會使用和Action名字一樣。但是，如果你要自己選則View，也可以。
因此，簡單來說，打造一個框架，讓大家有一致的習慣來寫程式，減少互相的不同。
Asp .Net Mvc 問題在那裡？
其實Mvc真的是一個很容易開發的框架，但是因為它的設計理念是給任意類型的網站使用，因此他只有做到最少的部份。
因此像一些常用的東西，例如logging他就不會做在裡面（也不需要做在裡面），而是讓我們自由發揮。通常這些通用行的東西每一個專案都差不多，每一次都要重複copy and paste其實是很浪費時間而且整體使用上面又不是很方便。因此，以Mvc為基準在往上蓋一層我們自己常用的東西，那麼我們開發速度就會快很多。
適合什麽樣的人看？
這系列只要對於Mvc開發有興趣的都可以看看。但是不會介紹Mvc的基礎（會介紹一些提到的其他概念的基礎，例如IoC），因此至少對於Mvc要有基本的認識。 下面是一個我之前做過介紹Mvc的Slide，如果裡面內容都大概了解，那麼這系列的內容看起來不會有問題。
其他注意事項
這系列其實很多部份都是可以獨立拆出來使用，適合我的框架不一定適合你。因此，應該要針對你們的習慣來微調甚至是完全翻掉我所介紹的內容。
正常情況下，屬於框架部份應該要拆出來成為別的Library Project，但是爲了簡單Demo，這裡面的範例就不會在拆project，但是在實務上要，這樣才能夠通用於不同案子。
我的程式碼大部份都是出自於網路，很少是（但是還是有）我完全從無到要自己想出來的內容。我頂多是把蒐集到的東西整合， 或者使用別人的Idea在重寫適合我情況的程式碼。因此，假設我還找得到的話，我會儘量放上原始的reference作為參考。
我這個框架參考了很多Matt Honeycutt的Fail-Tracker(Github) 專案，他有在一個研討會講過 Build Your Own Application Framework with ASP.NET MVC 3 (Youtube)， 有興趣的可以看看他的source code和演講。
最後，希望大家有任何指教都不要客氣，並且讀完都有收穫。
沒有留言 :
張貼留言