enum其實內部儲存的形態還是int，所以任何一個int都可以直接cast成為某一個enum type，這樣就可以用那個enum的形態來操作這些值，在撰寫和閱讀程式上面就會變得比較乾淨和一目了然。
Entity Framework在Code First模式下要定義一個enum非常的簡單，只需要把type設定成為那個enum，Entity Framework就會聰明到把DB的對應欄位開成int，並且儲存和讀取的時候幫忙自動轉換。
但是當使用Database First模式的時候，因為Designer從DB讀取回來只會把int當做int，因此要他自動產出enum是需要做一些設定。
這一篇將會介紹把int轉成enum如何做到，並且需要注意那些地方。
時間過的非常快，一眨眼30天就過去了，到目前為止框架的介紹也到了一個階段，希望大家在這一系列有得到一些有幫助的內容。
下面將會用一個同事幫忙畫的30天所介紹的框架整個架構圖，並且快速回顧一下每一個部份在那裡作了介紹。
這一整個系列主要目的是給各位未來需要建立自己框架的時候的一個起點，框架這個東西其實是要看整個專案和團隊的需求來建制。因此，這一系列的介紹只是給各位一些思考的方向和內容。
上一篇介紹完了在Mvc的框架裡面，用Json方式傳遞資料的問題之後，接下來將會看這些問題將會如何解決。
隨著前端處理的需求越來越高和前端框架的進化，前端變的更加容易，並且給更好的使用者體驗，身為開發者通常都需要使用到AJAX的技術，避免使用者需要一直切換和刷新頁面。
Mvc裡面提供了非常好框架，讓要回傳JSON變的非常方便，但是有些地方做的還是有點不夠好。
因此，這一篇將會介紹Mvc處理不好的地方和如何修正的概念內容，下一篇在介紹如何實作。
在上一篇介紹完了什麽是Model Metadata和Mvc的Html Helper如何利用Metadata來產生開發者想要的Html內容，在這一篇將會介紹框架如何能夠提供一些基礎架設方便產生和我們view能夠對應的Model Metadata。
Service層的部份到目前為止已經介紹了基本的CRUD，搜索方面的自動處理和一些資料驗證的部份。是時候來切換一下看在View的部份框架還能夠幫到什麽。
在這一篇將會介紹所謂的Model Metadata，並且概念上來說如何用框架打造一些好用的功能，並且在下一篇來實作。
在上一篇介紹完了如何顯示搜索表單之後，一個基本的通用搜索功能就完成了。
不過，其實有些部份還可以在加強，舉例來說，目前搜索是一定要完全符合才搜索的到，但是這樣就失去了很多好處，畢竟如果完全符合才搜索的到，那基本上等於搜索不到。
還有，假設今天我們搜索結果是要給使用者看的，通常都會有所謂的上下架起訖時間和是否啟用，當符合條件才可以看，這一部份其實自動搜索也可以幫到我們。
因此這一篇將會介紹未來如何在擴充自動搜索功能和在搜索做一些客制處理，符合只搜索出前臺使用者看的條件。
在上一篇介紹完了Service如何自動處理搜索和Controller如何呼叫這個Service之後，接下來就要看view將會如何呼叫，並且透過一些Helper方便產生有正確RouteValue的連接。
在上一篇介紹完了如何動態產生Linq條件之後，在這一篇，將會透過Reflection和Dynamic Linq Query來讓Service層，能夠在不做任何事情的情況下，自動對資料做過濾，並且轉成對應的ViewModel配上分頁。
在上一篇介紹完了會使用到的ViewModel之後，接下來就是實際的商業邏輯，也就是實際做搜索和產生資料的部份。
在這一篇，將會介紹如何透過Service層和ViewModel的搭配，讓使用起來變的更加方便。
搜索頁面無疑是任何系統必須要有的功能，同時要做出搜索頁面需要很多不同的地方：需要注意搜索條件，分頁的處理和結果的呈現。
這些處理其實如果沒有統一的做法，會很容易造成每個人用不同的方式做處理，因此這一篇將來介紹，如何透過框架被處理變的更加簡單。
這一篇，回到Controller常常需要做的一件事情，那就是當如果欄位屬於下拉式選單的時候，需要準備好下拉式清單的資料。
如果用的是預設的方式去產生下拉式選單其實有很多問題，這一篇想透過框架的方式，讓產生下拉式清單的資料能夠自動化。
在任意的Application裡面，都一定需要儲存資料。而這些資料的正確性是非常重要。舉例來說，以一篇部落格文章來說，這篇文章一定要有“標題”和“作者”，如果沒有這兩個資訊，這篇部落格文章更本就不算是文章。因此，確認進入資料庫的內容的資料是否正確（或者說符合領域裡面的規則），這就是資料正確性。
在Mvc裡面，有一個非常好的基本資料驗證服務，也就是用DataAnnotation定下欄位基本規則，讓Mvc在Model Binding的時候就會做基本的資料驗證。
但是那個只是單一的資料驗證，邏輯性的資料驗證呢？例如，需要和另外一個資料庫欄位做比對。這個光靠DataAnnotation是不夠的，只能夠在service層級來做這方面的資料驗證。
在來，當資料要實際儲存的時候Entity Framework這邊也會有實際DB欄位的資訊，有時候會和DataAnnotation設定的不一樣，導致儲存的時候炸掉。
上面提到3個層面，其實並沒有一個統一整合的東西把它們包在一起，導致在開發專案的時候，每一個人處理這三個層面的方式都不一樣。
因此，接下來要看的是，框架如何把這些驗證的地方整合在一起。
在上一篇，介紹了如何處理檔案上傳的部分。但是，裡面處理上傳檔案的邏輯是放在Mvc的Action裡面。
這個有一些壞處，首先，和邏輯相關的不應該寫在Controller裡面，因為Controller的工作很簡單，就只是決定Model的資料，和顯示的View是哪一個。把處理這種邏輯放在Controller裡面破會了所謂的關注點分離（SoC）的概念。
再來屬於SoC的衍生，因為如果邏輯寫在了Controller裡面，未來如果要替換邏輯或者需要做一些測試的時候，更本不好做。加上，如果別的地方也需要同樣邏輯的時候，更本沒有辦法通用。
因此，這一篇將會介紹如何把邏輯抽到Service層裡面。
在網站裡面，通常都會需要讓使用者上傳檔案，好方便前臺或者別的顯示這個資訊的地方來下載這個對應的檔案。
在Mvc裡面，有所謂的HttpPostedFileBase可以方便我們接到前端input是file的檔案。這個檔案通常會被存到Server的某一個位置之後，路勁才會儲存到DB 裡面，下次顯示的時候顯示的是這個檔案的路徑。
處理HttpPostedFileBase的邏輯其實還滿常見，如果框架能夠把這一部份也處理掉的話，又可以減少我們煩惱這些細節的部份，提升開發效率。
這一篇我們將來看一下如何做到。
在上一篇介紹完了什麽是Service層，和爲什麽要使用Service層。在這一篇，將會把CRUD裡面的方法先抽到Service層裡面，因此Controller不在直接和Data Access Layer溝通，而是透過Service層來和Data Access Layer溝通。
在定義Service功能的時候，將會使用泛型的方式讓程式碼能夠通用，然後各自在繼承通用型的方法來提供個別功能的客制。
在這一篇將會介紹爲什麽對框架來說有一個BaseController讓所有的Controller來繼承很重要，並且介紹一個簡單的強型別的RedirectToAction讓所有繼承這個BaseController的可以來使用。
透過這個強型別的RedirectToAction讓在寫Code的時候，不要犯下寫錯Action的名字，或者Action名字改了但是對應的RedirectToAction沒有改到的低級錯誤。
到目前為止，已經介紹了很多屬於基礎建設的部份。從核心的DI用Autofac開始，再到那裡都使用的到的Log服務。再來介紹了ViewModel和如何透過框架來讓對應變得更加簡單。最後介紹了透過Repository 和 Unit of work，使得實際的DAL層級能夠被abstraction出來。
在這一篇，將會介紹比較偏向Controller層級的內容，也就是每一個application一定會使用到的：如何提供一種一致性的服務用於從Server傳遞訊息到客戶端？
在上一篇介紹完了Repository Pattern，我們能夠抽離實際在做儲存的動作，讓我們在替換實際儲存動作更加容易。
但是光靠一個Repository Pattern其實還是有些缺陷，因此，通常來說會實作Unit of Work pattern搭配Repository pattern達到一個比較完美的狀態。
在上一篇介紹完了如何讓ViewModel和Entity之間的轉換透過AutoMapper變的更簡單，然後透過框架讓設定ViewModel和Entity之間的對應關係變的容易。
在這一篇，將會看Data Access Layer （DAL）的部份，也就是儲存資料層的部份。
在上一篇我們介紹了AutoMapper的設定和用法，使用起來肯定比自己手動做左邊倒到右邊還要簡單。
不過AutoMapper也不是沒有它自己的問題，最麻煩的地方在於設定Entity和Class之間的對應。這一篇要探討的就是，如何透過框架來減少這方面的設定。
在上一篇介紹完ViewModel的好處之後，留下的問題是，ViewModel雖然有帶來好處，但是ViewModel和實際Entity之間的對應其實是很麻煩的一件事情，那麼我們如何能夠簡化對應的邏輯呢？
這時候就是AutoMapper這個套件入場的時候。
在這一篇我們將來看一下在寫Mvc裡面最重要的一個概念，也就是強型別的View（Strong Type View）和ViewModel。
到目前為止，應該對於Autofac的使用有了基本的了解。在上一篇用了一個簡單的Log服務來說明Autofac如何和Mvc結合。
Log屬於任何一個系統必須有的服務，因此在這一篇，我們打造真的Log服務。
在上一篇我們介紹了Autofac的基本概念，還有它裡面比較常用的專有名詞，詳細對於Autofac有了一些了解。
在這一篇，我將會介紹如何讓我們在Asp .Net Mvc裡面，簡單的使用Autofac作為我們的DI Container。
在上一篇：IoC基本概念介紹介紹了IoC和DI的概念。在最後提到了，如果沒有一個東西幫我們管理DI，那麼其實整個的彈性設計還是無法彈性起來。
因此在這一篇，我們就來看一下其中一個比較常用的DI Container：Autofac。
在實際開始進入Asp .net Mvc之前，我們需要先來看一下一個很重要的概念，那就是IoC。
可以說IoC是框架的核心，基本上只要具備一定規模的框架，通常都會使用IoC和DI的搭配，因此我們需要先瞭解它的概念才能夠實際開始我們的框架開發。
一眨眼一年就過去了，去年參加鐵人賽的心情彷如昨日。
經過一年的時間，終於又回來專注於開發我比較習慣的環境，也就是Asp .Net Mvc。
因此相較於去年的主題“C# Web 開發 跳到 Java Web開發”，今年的主題“以Asp .Net MVC 5 為基礎，建立自己的程式開發框架”難度比去年高，同時也是一直以來我想要做的事情。
希望今年也能夠帶給大家一些幫助。
