比較方式: 對相同的資料表讀取 1000 次，來比較速度。
資料庫為 MS SQL

這裡做了 4 個 Case:

Case 1: 
使用 Entity Framework，DbContext 為每次 new 一個。

Case 2:
使用 Entity Framework，使用同一個 DbContext。

Case 3:
用 DAO，轉為 Data Table 的格式 (使用 DtFromSql)。

Case 4:
使用 Dapper。

專案啟動時的記憶體使用量約為:  123 MB



測試一:
第一次讀取
Case 1, 時間: 3673.0303 ms, 記憶體: 566 MB

Case 2, 時間:  3889.9379 ms, 記憶體: 304 MB  (這個時間有時會測試到 3000 ms)

Case 3, 時間:  1665.7748 ms, 記憶體: 205 MB

Case 4, 時間:  1639.7211 ms, 記憶體: 193 MB

讀取五次
Case 1, 時間: 1984.6395, 記憶體: 544MB (有發生 GC)


Case 2, 時間:  2367.9792 ms, 記憶體: 627 MB (沒有發生 GC)


Case 3, 時間:  1395.1132 ms, 記憶體: 280 MB (有發生 GC)



Case 4, 時間:  1531.3555 ms, 記憶體: 271 MB


結果: Dapper 看來完勝，速度上和直接使用 DAO 轉進 Data Table 的速度相近。但 Dapper 傳回的結果已經轉換為物件 List， 操作上會更為方便。

Entity Framework 一如預期的較慢，且花費較多的記憶體。但和想像中最大的差異是，使用同一個 DbContext 比 new 1000 個 DbContext  的速度還要慢， 花費的記憶體在 GC 之後，差異不大。

所以不一定要用 DI 注入 DbContext, 在各 function 中一直傳遞 DbContext. 在 Static 的 function 中，可以安心的 new 一個 DbContext 出來使用吧，只是要記得用 using 哦，否則可能會有 connection 沒有關閉的問題。


 

*分解元組(Deconstructing tuples)的支援必須要至少C# 7.0以上*

以前一個funtion如果需要回傳複數個參數你會怎麼做呢?

1.可能會定義一個物件，在回傳的時候宣告並將值塞進去return。(為了一個function而去定義，好醜...)
2.又或者是將回傳參數型別直接改成dynamic，回傳時直接使用匿名物件。(performance炸裂!!!)

如果你使用了上面兩種方式...請一定!一定!!一定!!!要把這篇文章看完。

先來說說在C#7.0以前的處理方法，在呼叫function之前先將欲接收的參數宣告好並傳入。



但是這樣做有幾個缺點，
1. 當傳入的參數與傳出的參數一多起來，function定義時的參數會又臭又長。
2. 使用這個function前每次都需要宣告變數，不累嗎?
3. 不管你要不要使用這個參數，你都一定要傳入，因為ref與out不能有預設值。

接下來...讓我與各位介紹 " 元 組 元 素 "!!! (Tuple)

早上好台灣，現在我有Tuple。我很喜歡Tuple，但是速度與激情9比...咳咳...沒事。

先來個簡單的範例

定義一個funciton JohnCena

然後我們就可以很漂亮的一次性取得JohnCena的姓名、出生日期、國籍、年齡等等資料!

 
假如你的參數需要在外面先行宣告也沒問題!



而從C#10開始，甚至可以混合使用也沒關係!



這樣我們就輕鬆解決了以前的兩個缺點了，而要解決最後一個缺點更是簡單，
只需要將你想要丟棄(discard)或是用不到的那個參數使用UnderLine( _ )就可以囉!



元組元素的基礎講完了再來說說解構元素的部分
建構式想必大家都已經很熟悉了



但是'分解式'你有聽過嗎?
顧名思義就是可以定義物件被指派出去的參數!
驚不驚喜! 意不意外?

使用的方法就是在class底下新增一個Deconstruct function



如此一來我們就可以來試試看將John Cena解ㄊ一.... 分解!



建構式可以多載，分解式當然也可以!



以上就是這次的內容，有沒有覺得Coding時的可玩性又更好了呢?
不過要提醒一點，目前解構式並無法使用查看定義來移置相對應的位置，
對於可讀性會有不小的影響，但如果你想要把某個東西藏起來不讓你同事找到... (請不要這樣做!)
這次的範例也歡迎到我的GitHub參考囉!

06/09/2022   由Bike 補充
 
可以將function的回傳參數先行命名!!
直接當成物件使用，對開發效率與可讀性有著明顯的提升，相信會是未來的趨勢。

另外要道歉並修正之前將Deconstruct翻譯成解構式的錯誤
Destruct (解構式)指的是class生命周期結束前執行的function
使用方式是class名稱為dunction名稱並在前面加上波浪符號 '~'
Deconstruct的翻譯應該為分解式

我們的目標是在啟動時，掛一個 global filter 來檢查上傳的檔案附檔名，避免上傳未預期的可執行檔。使用 global filter 可以防止程式設計師忘了做檔案檢查，發生危險。我們目前用到的 .Net Framework 有兩個類別，一個是 System.Web.Http.ApiController，另一個是 System.Web.Mvc.Controller，兩個要分開處理。

1. Web API (System.Web.Http.ApiController)
.Net Framework 的 Web API 2 在接收檔案時，必需使用 Request.Content.ReadAsMultipartAsync 把上傳的資料存入 MultipartMemoryStreamProvider 之後再來處理。
範例如下: 

    public class UploadController : ApiController

    {

        public async Task<object> PostFormData()

        {

            var provider = new MultipartMemoryStreamProvider();



            if (! Request.Content.IsMimeMultipartContent())

            {

                return "no file";

            }



            //要注意這裡的 await

            await Request.Content.ReadAsMultipartAsync(provider);



            foreach (var content in provider.Contents)

            {

                if (content.Headers.ContentDisposition.FileName != null)

                {

                    string localFilename = content.Headers.ContentDisposition.FileName.Replace("\"", "");

                    System.IO.Directory.CreateDirectory(HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/"));

                    string filename = HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/" + localFilename);

                    if (System.IO.File.Exists(filename))

                    {

                        System.IO.File.Delete(filename);

                    }



                    using (var fileStream = new FileStream(filename, FileMode.Create, FileAccess.Write))

                    {

                        var contentStream = await content.ReadAsStreamAsync();

                        await contentStream.CopyToAsync(fileStream);

                        Trace.WriteLine("Save To" + filename);

                    }

                }

            }

            return "OK";

        }

    }

程式碼中有個地方我沒有注意到。我一開始是用 Request.Content.ReadAsMultipartAsync(provider); 把資料讀進 provider，但前方沒有加上 await，造成有時讀不到檔案的情況，再次提醒自己 Async 和 Await 的關係。

直覺的想法是在 filter 中執行一樣的程式碼，不存檔，只要抓出檔名來檢查即可。但這時遇到一個問題 Request.Content.ReadAsMultipartAsync 不能執行兩次，Google 了一陣子，也沒找不到類似 seek(0) 的操作。所以只好自己寫一個暫存的機製。

這裡決定使用 System.Web.HttpContext.Current.Items 來暫存 provider，最後的 OnActionExecutingAsync 結果如下:

        /// <summary>

        /// 檔案檢查

        /// </summary>

        /// <param name="actionContext"></param>

        /// <param name="cancellationToken"></param>

        /// <returns></returns>

        public override async Task OnActionExecutingAsync(HttpActionContext actionContext, CancellationToken cancellationToken)

        {

            Trace.WriteLine("ApiCheckFile OnActionExecutingAsync");



            var request = actionContext.Request;

            if (!request.Content.IsMimeMultipartContent())

            {

                return;

            }



            var provider = new MultipartMemoryStreamProvider();

            await request.Content.ReadAsMultipartAsync(provider);



            //把 provider 存入 System.Web.HttpContext.Current.Items 之中，以便在 controller 中再度使用

            System.Web.HttpContext.Current.Items["MimeMultipartContentProvider"] = provider;



            foreach (var content in provider.Contents)

            {

                if (content.Headers.ContentDisposition.FileName != null)

                {

                    var filename = content.Headers.ContentDisposition.FileName.Replace("\"", "");

                    Trace.WriteLine(filename);



                    var ext = System.IO.Path.GetExtension(filename);

                    if (!".jpg,.jpeg,.png".Contains(ext.ToLower()))

                    {

                        throw new Exception("file format error.");

                    }

                }

            }



            return;

        }

而 controller 中的 Action 則改為以下的版本；本版本中，除了把上傳的檔案存檔以外，還有讀取 form data 中其它欄位的範例:

        public async Task<object> PostFormData()

        {

            //改由 HttpContext.Current.Items 中，讀取資料。

            MultipartMemoryStreamProvider provider = (MultipartMemoryStreamProvider)System.Web.HttpContext.Current.Items["MimeMultipartContentProvider"];



            //如果沒有經過 filter，provider會是 null, 這時就要直接由 Request.Content 讀入 provider

            if (provider == null)

            {

                provider = new MultipartMemoryStreamProvider();

                Request.Content.ReadAsMultipartAsync(provider);

            }



            foreach (var content in provider.Contents)

            {

                if (content.Headers.ContentDisposition.FileName != null)

                {

                    string localFilename = content.Headers.ContentDisposition.FileName.Replace("\"", "");

                    Trace.WriteLine("FileName: " + localFilename);

                    Trace.WriteLine("FileName: " + @"~/App_Data/Temp/" + localFilename);

                    System.IO.Directory.CreateDirectory(HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/"));

                    string filename = HttpContext.Current.Server.MapPath(@"~/App_Data/Temp/" + localFilename);

                    if (System.IO.File.Exists(filename))

                    {

                        System.IO.File.Delete(filename);

                    }



                    using (var fileStream = new FileStream(filename, FileMode.Create, FileAccess.Write))

                    {

                        var contentStream = await content.ReadAsStreamAsync();

                        await contentStream.CopyToAsync(fileStream);

                        Trace.WriteLine("Save To" + filename);

                    }

                }

                else

                {

                    var contentStream = await content.ReadAsStreamAsync();

                    var reader = new System.IO.StreamReader(contentStream);

                    var data = reader.ReadToEnd();

                    Trace.WriteLine("data: " + data);

                }

            }

            return "OK";

        }

以上是展示 Web Api 的 Filter。

如果是 MVC 的 Controller，就簡單多了，直接讀取 actionContext.HttpContext.Request.Files 裡面各檔案的 FileName 即可。不過也遇到了一個和直覺不同的地方，對 actionContext.HttpContext.Request.Files 居然不能用 foreach 請見下方註解掉的地方。也許是我的用法有問題，如果有人找到可以使用的方法也麻煩告知。

        public override void OnActionExecuting(ActionExecutingContext actionContext)

        {

            Debug.WriteLine("MvcCheckFileFilter OnActionExecuting");

            if (actionContext.HttpContext.Request.Files.Count > 0)

            {

                for (int i = 0; i < actionContext.HttpContext.Request.Files.Count; i++)

                {

                    System.Web.HttpPostedFileBase file = actionContext.HttpContext.Request.Files[i];

                    if (System.IO.Path.GetExtension(file.FileName) != ".jpg")

                    {

                        throw new Exception("file format error.");

                    }

                    Debug.WriteLine(i + "MvcCheckFileFilter OnActionExecuting File type: " + file.FileName.ToString());

                }

            }



            //以下寫法會發生錯誤: 無法將類型 'System.String' 的物件轉換為類型 'System.Web.HttpPostedFileBase'。

            //foreach (HttpPostedFileBase file in actionContext.HttpContext.Request.Files)

            //{

            //    if (System.IO.Path.GetExtension(file.FileName) != ".jpg")

            //    {

            //        throw new Exception("file format error.");

            //    }

            //}

        }

最後是把 filter 掛在 global filter 裡，如下:
Web API Controller 的部份:
在 WebApiConfig.cs 裡加上 config.Filters.Add(new ApiCheckFile()); 見下圖:
 

附帶一提，Register 是在 global.asax 裡被叫用的。微軟的架構常常這樣，硬是拉到另一個目錄的獨立檔案裡，如果 global.asax 沒有這一行，不知所以的人，在 App_Start 裡，建立了一個 WebApiConfig.cs 然後會發現完全沒做用... 見下圖

 
MVC Controller 的部份，
在 FilterConfig.cs 中，加上 filters.Add(new MvcCheckFileFilter()); 如下圖
 

一樣是在 global.asax 中呼叫  FilterConfig.RegisterGlobalFilters，見下圖:

 
不過有趣的地方是，在 global.asax 裡, WebApiConfig.Register 和 FilterConfig.RegisterGlobalFilters 的叫用方法不同，一個是把 function 當作變數，一個是直接呼叫 function, 大家可以比較一下。

附註 1, 關於 OnActionExecutingAsync 和 OnActionExecuting:

Web API 的 filter 中，提供了 OnActionExecutingAsync 和 OnActionExecuting 兩個 method 可以 override ，我實驗的結果是如果兩個 method 都 override 了，只有 OnActionExecutingAsync 會被呼叫。

MVC 的 filter 中，只有 OnActionExecuting 可以 override。
 

對於PC版大尺吋的螢幕，當網站要 feed 資料到 facebook 時，可以使用 javascript SDK 的
FB.ui => method:'feed' 方式處理，參考位置。此方法會popup小視窗讓user可以分享資料出去。

但是遇到手機版網頁就有點麻煩，實測上手機版的 chrome 會出現轉不停的情況，無法分享；而iPhone則是另開新頁面處理，可以成功但是會多一個分頁。所以手機版網頁建議使用 redirect 方式處理分享機制，參考位置
​

    var fbUrl = "https://www.facebook.com/dialog/feed?" +

    "app_id=122465741241119&display=touch" +

    "&link=" + encodeURIComponent("http://www.shopunt.com/tch/FixPage.aspx?id=525") +

    "&picture=" + encodeURIComponent("http://www.shopunt.com/tch/event/2014-nail-enrollment/fb_200x200.jpg") +

    "&description=" + encodeURIComponent("市價不斐的光療DIY教學，UNT傾囊相授！10場巡迴免費教學，讓妳輕鬆掌握光療DIY訣竅，並搶先體驗秋冬最新流行色！現場打卡，再送時尚美甲工具組") +

    "&redirect_uri=" + encodeURIComponent("http://www.shopunt.com/tch/event/2014-nail-enrollment/Handler.ashx?fun=FBCallback");

​

當然以 redirect 處理與 javascript 方式處理是兩種不同的方式，redirect 方式的 callback 網址 (redirect_uri)要接收facebook 導回的 post_id , javascript 方式則是 callback function 處理 post_id

1. 在要匯出的 DB 上, 按右鍵, 選取工作 -->  產生令碼.

 

2. 歡迎頁

 


 3. 選取資料庫
 

4. 設定選項, 記得要選取 "編寫資料的指令碼"
 

5. 選取資料表
 

6. 選擇要匯出的資料表
 

7. 指定 Script 要儲存的位置
 

8. 檢視摘要
 

9. 完工