2014年10月29日 星期三

[iThome 第七屆鐵人賽 30] 終篇 總結

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

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

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


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

上一篇介紹完了在Mvc的框架裡面,用Json方式傳遞資料的問題之後,接下來將會看這些問題將會如何解決。


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

隨著前端處理的需求越來越高和前端框架的進化,前端變的更加容易,並且給更好的使用者體驗,身為開發者通常都需要使用到AJAX的技術,避免使用者需要一直切換和刷新頁面。

Mvc裡面提供了非常好框架,讓要回傳JSON變的非常方便,但是有些地方做的還是有點不夠好。

因此,這一篇將會介紹Mvc處理不好的地方和如何修正的概念內容,下一篇在介紹如何實作。


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

在上一篇介紹完了什麽是Model Metadata和Mvc的Html Helper如何利用Metadata來產生開發者想要的Html內容,在這一篇將會介紹框架如何能夠提供一些基礎架設方便產生和我們view能夠對應的Model Metadata。


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

Service層的部份到目前為止已經介紹了基本的CRUD,搜索方面的自動處理和一些資料驗證的部份。是時候來切換一下看在View的部份框架還能夠幫到什麽。

在這一篇將會介紹所謂的Model Metadata,並且概念上來說如何用框架打造一些好用的功能,並且在下一篇來實作。


2014年10月24日 星期五

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

在上一篇介紹完了如何顯示搜索表單之後,一個基本的通用搜索功能就完成了。

不過,其實有些部份還可以在加強,舉例來說,目前搜索是一定要完全符合才搜索的到,但是這樣就失去了很多好處,畢竟如果完全符合才搜索的到,那基本上等於搜索不到。

還有,假設今天我們搜索結果是要給使用者看的,通常都會有所謂的上下架起訖時間和是否啟用,當符合條件才可以看,這一部份其實自動搜索也可以幫到我們。

因此這一篇將會介紹未來如何在擴充自動搜索功能和在搜索做一些客制處理,符合只搜索出前臺使用者看的條件。


2014年10月12日 星期日

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

搜索頁面無疑是任何系統必須要有的功能,同時要做出搜索頁面需要很多不同的地方:需要注意搜索條件,分頁的處理和結果的呈現。

這些處理其實如果沒有統一的做法,會很容易造成每個人用不同的方式做處理,因此這一篇將來介紹,如何透過框架被處理變的更加簡單。


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

這一篇,回到Controller常常需要做的一件事情,那就是當如果欄位屬於下拉式選單的時候,需要準備好下拉式清單的資料。

如果用的是預設的方式去產生下拉式選單其實有很多問題,這一篇想透過框架的方式,讓產生下拉式清單的資料能夠自動化。


2014年10月9日 星期四

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

在任意的Application裡面,都一定需要儲存資料。而這些資料的正確性是非常重要。舉例來說,以一篇部落格文章來說,這篇文章一定要有“標題”和“作者”,如果沒有這兩個資訊,這篇部落格文章更本就不算是文章。因此,確認進入資料庫的內容的資料是否正確(或者說符合領域裡面的規則),這就是資料正確性。

在Mvc裡面,有一個非常好的基本資料驗證服務,也就是用DataAnnotation定下欄位基本規則,讓Mvc在Model Binding的時候就會做基本的資料驗證。

但是那個只是單一的資料驗證,邏輯性的資料驗證呢?例如,需要和另外一個資料庫欄位做比對。這個光靠DataAnnotation是不夠的,只能夠在service層級來做這方面的資料驗證。

在來,當資料要實際儲存的時候Entity Framework這邊也會有實際DB欄位的資訊,有時候會和DataAnnotation設定的不一樣,導致儲存的時候炸掉。

上面提到3個層面,其實並沒有一個統一整合的東西把它們包在一起,導致在開發專案的時候,每一個人處理這三個層面的方式都不一樣。

因此,接下來要看的是,框架如何把這些驗證的地方整合在一起。


2014年10月8日 星期三

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

在上一篇,介紹了如何處理檔案上傳的部分。但是,裡面處理上傳檔案的邏輯是放在Mvc的Action裡面。

這個有一些壞處,首先,和邏輯相關的不應該寫在Controller裡面,因為Controller的工作很簡單,就只是決定Model的資料,和顯示的View是哪一個。把處理這種邏輯放在Controller裡面破會了所謂的關注點分離(SoC)的概念。

再來屬於SoC的衍生,因為如果邏輯寫在了Controller裡面,未來如果要替換邏輯或者需要做一些測試的時候,更本不好做。加上,如果別的地方也需要同樣邏輯的時候,更本沒有辦法通用。

因此,這一篇將會介紹如何把邏輯抽到Service層裡面。


2014年10月7日 星期二

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

在網站裡面,通常都會需要讓使用者上傳檔案,好方便前臺或者別的顯示這個資訊的地方來下載這個對應的檔案。

在Mvc裡面,有所謂的HttpPostedFileBase可以方便我們接到前端input是file的檔案。這個檔案通常會被存到Server的某一個位置之後,路勁才會儲存到DB 裡面,下次顯示的時候顯示的是這個檔案的路徑。

處理HttpPostedFileBase的邏輯其實還滿常見,如果框架能夠把這一部份也處理掉的話,又可以減少我們煩惱這些細節的部份,提升開發效率。

這一篇我們將來看一下如何做到。


2014年10月6日 星期一

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

在上一篇介紹完了什麽是Service層,和爲什麽要使用Service層。在這一篇,將會把CRUD裡面的方法先抽到Service層裡面,因此Controller不在直接和Data Access Layer溝通,而是透過Service層來和Data Access Layer溝通。

在定義Service功能的時候,將會使用泛型的方式讓程式碼能夠通用,然後各自在繼承通用型的方法來提供個別功能的客制。


2014年10月4日 星期六

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

在這一篇將會介紹爲什麽對框架來說有一個BaseController讓所有的Controller來繼承很重要,並且介紹一個簡單的強型別的RedirectToAction讓所有繼承這個BaseController的可以來使用。

透過這個強型別的RedirectToAction讓在寫Code的時候,不要犯下寫錯Action的名字,或者Action名字改了但是對應的RedirectToAction沒有改到的低級錯誤。


2014年10月3日 星期五

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

到目前為止,已經介紹了很多屬於基礎建設的部份。從核心的DI用Autofac開始,再到那裡都使用的到的Log服務。再來介紹了ViewModel和如何透過框架來讓對應變得更加簡單。最後介紹了透過Repository 和 Unit of work,使得實際的DAL層級能夠被abstraction出來。

在這一篇,將會介紹比較偏向Controller層級的內容,也就是每一個application一定會使用到的:如何提供一種一致性的服務用於從Server傳遞訊息到客戶端?


2014年10月2日 星期四

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

在上一篇介紹完了Repository Pattern,我們能夠抽離實際在做儲存的動作,讓我們在替換實際儲存動作更加容易。

但是光靠一個Repository Pattern其實還是有些缺陷,因此,通常來說會實作Unit of Work pattern搭配Repository pattern達到一個比較完美的狀態。