Programming

以下包含暫時解法，因為是直接動WordPress Kernel 1. WordPress 網址無法轉址（Permalinks） 要修改 web.config 檔 <?xml version="1.0"...

Most of the time you don't need...

Problem : During compilation of a legacy project...

在上一篇介紹完了如何顯示搜索表單之後，一個基本的通用搜索功能就完成了。 不過，其實有些部份還可以在加強，舉例來說，目前搜索是一定要完全符合才搜索的到，但是這樣就失去了很多好處，畢竟如果完全符合才搜索的到，那基本上等於搜索不到。 還有，假設今天我們搜索結果是要給使用者看的，通常都會有所謂的上下架起訖時間和是否啟用，當符合條件才可以看，這一部份其實自動搜索也可以幫到我們。 因此這一篇將會介紹未來如何在擴充自動搜索功能和在搜索做一些客制處理，符合只搜索出前臺使用者看的條件。 同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-25-IndexPage-AutomaticSearch-improved.html 以Like的方式搜索 第一個要處理的是針對string類型的用like方式做搜索。要用Like方式做搜索，就要用到Linq裡面的Contain()語法： <!-- wp:paragraph --> <p>/// &lt;summary&gt;<br>/// 依照Search Form ViewModel的值來設定Where的內容。<br>///...

在上一篇介紹完了如何動態產生Linq條件之後，在這一篇，將會透過Reflection和Dynamic Linq Query來讓Service層，能夠在不做任何事情的情況下，自動對資料做過濾，並且轉成對應的ViewModel配上分頁。 同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-23-IndexPage-AutomaticSsearch.html Service層的處理 在處理搜索的部份，Service層將會需要： 透過Reflection取得要搜索的欄位 - 這邊要記得是不要base的欄位（不要那些例如目前在第幾頁，和一頁幾筆的那種）依照Reflection的欄位和Dynamic LInq Query組成搜索條件做搜索並且用Automapper把Entity...

在上一篇介紹完了會使用到的ViewModel之後，接下來就是實際的商業邏輯，也就是實際做搜索和產生資料的部份。 在這一篇，將會介紹如何透過Service層和ViewModel的搭配，讓使用起來變的更加方便。 同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-22-IndexPage-DynamicWhereLinq.html 功能描述 Service的流程大概如下： 依照SearchViewModel裡面的欄位去做DB搜索得出的結果將會用Automapper轉成要的SearchResultViewModel，並且透過PagedList.Mvc的方式把資料包住View方面的呈現 - 搜索表單可以做成通用的Partial 由於Service要做的事情也滿多的，因此整個Service層的實作會分幾篇來介紹。 Service依照SearchViewModel裡面的欄位去做搜索 這個部份其實要拆成兩塊： 動態組裝Linq條件 - Linq搜索的好處是強型別的條件，但是當我們希望Service自動依照欄位去做搜索的時候，Linq就不方便使用了。因此，我們需要先瞭解如何動態組裝Linq條件透 過Reflection取得搜索欄位和條件 -...

在上一篇介紹完了搜索功能的概念和思路之後，在這一篇開始要看實作的部份。 通常寫Mvc都是從Model開始，因此這一篇將來看一下搜索功能所會使用到的ViewModel 同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-21-IndexPage-ViewModel.html ViewModel的內容 首先，搜索的ViewModel必然會有兩個Property： 搜索條件搜索結果 因此，我們會先從這兩個部份的Property來看起。 搜索條件的ViewModel 搜索條件會有一定有的欄位和各個domain所需要的欄位，因此會先定義一個Base，好方便之後domain來繼承並且提供其他相關欄位。 一定會有的欄位像是： 每頁筆數目前頁數排序欄位排序順序 Domain相關的欄位就依照各自的需求，例如假設是一篇文章，可能會有以「標題」做搜索或者以「內文」做搜索。 因此，程式碼會如下： /// <summary> /// 搜索 Form 的 ViewModel base。定義搜索必須要有的相關欄位。 ///...

搜索頁面無疑是任何系統必須要有的功能，同時要做出搜索頁面需要很多不同的地方：需要注意搜索條件，分頁的處理和結果的呈現。 這些處理其實如果沒有統一的做法，會很容易造成每個人用不同的方式做處理，因此這一篇將來介紹，如何透過框架被處理變的更加簡單。 同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-20-IndexPage-concept.html 一般搜索頁面所會需要處理的內容 搜索頁面基本上就是所謂的Index頁面。這種頁面通常會有3個部份的內容： 搜索條件 - 通常應該會有一個搜索條件，讓使用者可以過濾資料的顯示搜索結果 - 依照搜索條件，去產生對應的結果做呈現和顯示分頁處理 - 通常會針對結果做分頁處理，例如如果有100筆，可能只希望一次呈現20筆，那麼就會有5頁。這些資訊的處理其實並沒有想像中的容易。 針對上面提到的3個部份的內容，其實都有一些底層的內容去處理，而這些如果沒有做好，很多時候都是在runtime的時候才會出錯，而不是...

這一篇，回到Controller常常需要做的一件事情，那就是當如果欄位屬於下拉式選單的時候，需要準備好下拉式清單的資料。 如果用的是預設的方式去產生下拉式選單其實有很多問題，這一篇想透過框架的方式，讓產生下拉式清單的資料能夠自動化。 同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-19-GenerateSelectListFroDropDownList.html 預設Scaffolding的問題 如果是Mvc Scaffolding內建的話，會在Controller的時候產生下拉式清單資料並且塞到ViewBag裡面。 這個最大的問題是：假設某一個地方有需要下拉式選單的資料，但是忘記產生了(最長發生這個問題是在Edit的時候，驗證失敗需要重新顯示View的時候)，畫面就會炸掉。 而且這個只有在runtime的時候才會發生，完全沒有辦法在compile的時候檢測出來。 假設有東西能夠保證需要下拉式清單的資料的時候，一定會產生出來，就不需要擔心到底有沒有忘記呼叫要把資料塞到ViewBag裡面。 這就是我們框架要解決的問題。 解決思路 首先，需要下拉式清單的資料的時候，就需要產生出來。能夠確認每一次需要的時候就會產生，就要透過Filter來做。 如 果透過Filter來處理產生的邏輯，那麼還需要準備資料給Filter，讓它產生對應的資料並且塞到ViewBag裡面。因此，ViewModel是最 適合的，因為在Filter裡面可以取得ViewModel的內容，因此可以做一個特殊的欄位，專門存放這些準備資料。 最後，在顯示的部份，就可以用一般的HtmlHelper產生即可。 實作內容 接下來就看看如何實作。 SelectListViewModel的定義 首先，定義一個SelectListViewModel的Class，這個Class將代表需要產生的下拉式選單： /// <summary> /// 代表一個要被產生的SelectList /// </summary> public...

在上一篇介紹了資料驗證的三個時機，在這一篇將會實作上一篇的內容。 同步發表於我的部落格：http://alantsai2007.blogspot.com/2014/10/BuildYourOwnApplicationFrameworkOnMvc-18-DataValidation-implement.html 基本流程 首先，需要定義出一個能夠用來裝錯誤訊息的資料載體。這個Class的用處只是方便我們在3段不同地方做驗證的時候，可以儲存錯誤訊息，並且在3層互相傳遞。 再來，會定一個Wrapper，把錯誤訊息包起來，並且提供一個方法回傳，驗證是否成功。 最後，在Controller那邊的驗證（ModelStateDictionary）和Repository儲存（如果驗證失敗會丟出exception）出現錯誤訊息的時候，把這些放在Wrapper 裡面，方便統一顯示資料驗證。 需要新增的Class和interface 首先先介紹會增加的interface和Class，然後才介紹如何實際做到Freamwork裡面。 定義裝載錯誤訊息的載體 基本上定義一個interface（IBaseError）代表一個錯誤訊息會有的欄位。基本上這個interface有兩個property，一個是儲存錯誤訊息的資訊，另外一個是儲存這個錯誤訊息對應到的Property。 因為，不是所有錯誤訊息都會有對應的欄位，因此，會用兩種實作，一個是PropertyError，代表這個錯誤訊息和Property有關聯（例如某一個欄位是必填欄位，那沒就是屬於這種類型的錯誤哦訊息）。 另外一種實作則是通用型錯誤訊息叫做GeneralError。這種錯誤是不會和某一個欄位有關的，因此只會有錯誤訊息的值，而不會有property欄位。 如果用Class Diagram表示就是： 裝在錯誤訊息的Class 接住Repository層的驗證錯誤邏輯 在Repository層如果驗證錯誤的話，Entity Framework會丟出一個Exception。 因此，為了處理這個部份，將會定義一個自訂的Exception，可以幫忙把Entity Framework的錯誤訊息包住成為IBaseError。 Class Diagram的樣子會是： Entity Framework驗證錯誤Exception包住的客制Exception 驗證的Dictionary 在Mvc裡面，ModelStateDictionary會存放錯誤訊息，並且透過HtmlHelper很方便的能夠把裡面錯誤訊息顯示出來。 但是為了避免和ModelStateDictionary綁死，因此會定義一個interface，提供需要的方法，然後在做一個ModelStateDictionary...