時間過的非常快，一眨眼30天就過去了，到目前為止框架的介紹也到了一個階段，希望大家在這一系列有得到一些有幫助的內容。

下面將會用一個同事幫忙畫的30天所介紹的框架整個架構圖，並且快速回顧一下每一個部份在那裡作了介紹。

這一整個系列主要目的是給各位未來需要建立自己框架的時候的一個起點，框架這個東西其實是要看整個專案和團隊的需求來建制。因此，這一系列的介紹只是給各位一些思考的方向和內容。

同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-30-Conclusion.html

**由於總結的連接有些多，因此下面的連接都是對應到我的部落格，不過文章內容和之前發佈的都一樣。**

整個框架結構圖

框架結構圖

Autofac

一開始就是先介紹了DI的概念和Autofac相關。整個框架的核心是DI，至於要使用什麼的DI Container是看個人喜好。

[iThome 第七屆鐵人賽 02] IoC基本概念介紹

[iThome 第七屆鐵人賽 03] Autofac基本介紹

[iThome 第七屆鐵人賽 04] Autofac和Asp .Net Mvc結合

Log

介紹完了Autofac之後，用了最常見的功能，Log服務來在深入介紹Autofac能夠做到什麼地步。

[iThome 第七屆鐵人賽 05] 打造第一個通用服務 - Log

ViewModel和AutoMapper

接下來是Mvc很常見的ViewModel和Model之間的轉換。介紹了為什麼要使用ViewModel，並且如何透過Automapper來讓ViewModel和Model之間的轉換變的簡單。

[iThome 第七屆鐵人賽 06] ViewModel的重要性

[iThome 第七屆鐵人賽 07] AutoMapper 介紹 - 簡單化Entity和ViewModel之間的轉換

[iThome 第七屆鐵人賽 08] 框架簡化建立AutoMapper對應的設定

Repository和Unit of Work

介紹完了Model和ViewModel之間用AutoMapper的轉換，實際看了如何實作常見的Repository + Unit Of Work來抽離Data Access Layer的功能。

[iThome 第七屆鐵人賽 09] 用Repository Pattern抽離對Entity Framework的依賴

[iThome 第七屆鐵人賽 10] 加上 Unit of Work，抽離Entity Framework的依賴就完美了

Alerts服務和BaseController

如何有一個共通傳遞訊息到前端的方法是很重要的，並且前端想用其他方式呈現這些資訊的做法也需要考慮進去。

[iThome 第七屆鐵人賽 11] 傳遞資訊到前端的通用型服務

也介紹了有一個共通Controller的重要性，不管是要增加共通方法到所有的Controller還是要把一些客制的ActionResult呼叫使用，都提供了一個很好的Wrapper。

[iThome 第七屆鐵人賽 12] BaseController的重要性

[iThome 第七屆鐵人賽 29] Javascript和Mvc溝通 - 實作篇

Service層的工作

SoC的概念非常重要，因此有了Service層來處理邏輯相關的內容。

[iThome 第七屆鐵人賽 13] Service層 - 概念篇

[iThome 第七屆鐵人賽 14] 把目前的CRUD功能放到Service層

這邊介紹了如何建立自己的Service層，有了Service層之後如何把一些內容自動化。

[iThome 第七屆鐵人賽 15] 處理檔案上傳

[iThome 第七屆鐵人賽 16] 處理檔案上傳 2 - 放到Service層

自動化搜索

任何application都需要能夠搜索，因此能夠處理共通的搜索邏輯是非常重要的，而Service能夠完全處理這些內容。

[iThome 第七屆鐵人賽 20] 搜索頁面 - 思考篇

[iThome 第七屆鐵人賽 21] 搜索頁面 - ViewModel的定義

[iThome 第七屆鐵人賽 22] 搜索頁面 - Service層的工作 -動態產生Linq條件

[iThome 第七屆鐵人賽 23] 搜索頁面 - Service層的工作 - 自動套用一般搜索條件

[iThome 第七屆鐵人賽 24] 搜索頁面 - Service層的工作 - View方面的處理

[iThome 第七屆鐵人賽 25] 搜索頁面 - Service層的工作 - 搜索在進化

資料驗證

任何Application都需要做資料驗證，因此介紹了如何把不同層級的錯誤訊息串接再起來，並且方便呈現。

[iThome 第七屆鐵人賽 17] 資料驗證 - 思路篇

[iThome 第七屆鐵人賽 18] 資料驗證 - 實作篇

SelectListFill：下拉式選項內容自動產生

能夠讓每一次都產生下拉式選單的內容可以避免掉一些只有在Runtime才測試的出來的問題。

[iThome 第七屆鐵人賽 19] 框架產生下拉式資料的內容

ModelMetadata 和 JsonResult

ModelMetadata可以讓我們用Convention的方式來產生一致的UI。

[iThome 第七屆鐵人賽 26] View相關的處理 - Model的Metadata介紹

[iThome 第七屆鐵人賽 27] View相關的處理 - 框架自動增加Model Metadata

自訂的JsonResult可以讓我們前端和後端溝通的時候變得更加容易。

[iThome 第七屆鐵人賽 28] Javascript和Mvc溝通 - 概念篇

[iThome 第七屆鐵人賽 29] Javascript和Mvc溝通 - 實作篇

結語

框架這個東西真的是要看團隊和看案子。並 不是所有的功能都需要，也並不是所有的做法都對。框架其實只是一些個人意見和個人喜好針對某些事情的處理做包裝和把一些細節隱藏起來讓開發著專注於重要的 問題：也就是解決客戶的問題，而不是一直重複debug一些疏忽的小事造成系統出問題。

這系列的文章其實只是給大家一個起點，希望對於大家有些幫助。