將前三篇有關「ASP.NET MVC Excel 匯入與匯出 - 簡單做」的範例程式碼給放到 GitHub 上面,有興趣的朋友可以直接上去看或是下載完整程式碼。
另外說明如果把範例程式的網站給發佈到 Windows Server 時,一些需要注意的地方。
將前三篇有關「ASP.NET MVC Excel 匯入與匯出 - 簡單做」的範例程式碼給放到 GitHub 上面,有興趣的朋友可以直接上去看或是下載完整程式碼。
另外說明如果把範例程式的網站給發佈到 Windows Server 時,一些需要注意的地方。
從 Visual Studio 2013 將 ASP.NET MVC 5 與 ASP.NET WebForms 的預設範本使用 Twitter Bootstrap 之後,這個原本就已經被許多網站開發人員所採用的前端 UI Framework 也讓更多的 ASP.NET 開發人員認識並使用它,這對於大多數的 ASP.NET WebForms 的開發人員會感覺有比較大的改變,因為平時所接觸的 UI 都是以 Server Controls 居多,對於 ASP.NET MVC 開發人員來說,使用 Bootstrap 來開發是比 WebForms 的人還早,而且也比較熟悉,畢竟 ASP.NET MVC 沒有那些可以拖拉放的 Server Control。
但使用 Bootstrap 時,不見得會把所有的標籤語法給記起來,當需要某些功能的時候才會到官網去找,或是到 Bootsnipp 或是 Bootply 等網站去找,不過最近有一個 Visual Studio 擴充功能剛好可以解決這項困擾,只要安裝好 Extension 之後,在開發的時候只要使用 code snippet 就可以快速產出 Bootstrap 的功能。
經歷了前兩篇的「匯入 Excel 簡單做」之後,有了匯入就會有匯出的功能,匯出 Excel 的功能可以使用很多方式來完成,例如直接使用 Open XML SDK、NPOI、EPPlus 或是一些需付費的第三方套件,這邊我會建議,如果專案預算允許的情況下,在穩定性以及日後維護的考量,可以考慮購買需付費的第三方套件。
這一篇文章的範例會延續前兩篇匯入 Excel 的內容,所以建議各位先看過這兩篇文章:
ASP.NET MVC 匯入 Excel 簡單做 - Part.1 檔案上傳
ASP.NET MVC 匯入 Excel 簡單做 - Part.2 匯入資料
上一篇完成了 Excel 的檔案上傳功能,那接下來要處理的就是已上傳 Excel 檔案的資料匯入,其實整個操作的流程會是檔案上傳完成後就直接進行 Excel 資料的匯入,我們就來完成這些功能吧。
做專案開發的時候常常會碰到這樣需求,就是 Excel 檔案的匯入與匯出,而做法的難易度與複雜度都會因為所要處理的匯出入資料格式與內容而異,所以在市場上就有許多的套件與解決方案,功能強大而且支援多樣性與客製化處理與操作的套件往往需要很高的授權費用,不過一分錢一分貨,但是唯有一句話永遠是真理……「免費的最貴」。
因為不想花錢買第三方套件來解決,所以就用土法煉鋼的方式來兜出一個解決方法,通常都要耗費相當多的時間,而且很多方法都是 Google Copy Paste 而來的,所以就會常常出現問題。
那麼這一篇也是一樣,看來也會是讓人 Google Copy Paste 的一篇文章,不過這一篇只會提供簡單做法的解決方式,針對單一個 Excel 檔案的單一 WorkSheet,然後匯入單一的 Table 裡,希望大家能夠了解做一個 Excel 匯入功能的基本流程與方法。
前一陣子完成了「ASP.NET MVC - CheckBoxList 與 ValidationMessage (ASP.NET MVC 5 with Bootstrap3)」與「ASP.NET MVC - CheckBoxList 與 ValidationMessage (ASP.NET MVC 4 without Bootstrap)」這兩篇有關於 CheckBoxList 與 ASP.NET MVC ValidationMessage 的應用,但這兩篇文章與之前有關 CheckBoxList 的文章都只有展示 CheckBoxList 的功能,並沒有實際針對在資料的 CRUD(Create, Read, Update, Delete)操作上去怎麼使用,所以這一篇文章就來說明怎麼在資料的 CRUD 操作去使用 CheckBoxList。
針對前幾天發布的幾篇文章,將文章的範例程式做整理然後放到 GitHub 上,因為有些朋友看了文章之後還是不太有感覺,不曉得是我文章的內容描述有問題還是文筆不好,所以就會有人反應看了文章之後也跟著做一遍卻發生問題,所以將範例程式放到 GitHub,這樣大家就可以直接下載然後執行。
前一篇「MiniProfiler 3 + ASP.NET WebForms + ADO.NET」是說明怎麼在 ASP.NET WebForms 與 ADO.NET 的情況下去怎麼使用 MiniProfiler 以及如何修改設定,同樣的在 twMVC#15 裡也有分享另一個套件「Glimpse」。
與 MiniProfiler 比較起來,Glimpse 不止是提供 EF 的 SQL Command 追蹤或執行方法的效能追蹤,此外還有提供多種的頁面訊息,讓我們在開發時可以掌握更多的資訊,這些在以前的文章都曾經有介紹過,可以查看部落格裡的 Glimpse 相關文章。
之前的文章都是以 ASP.NET MVC + Entity Framework 的情況下來做說明,而 Glimpse 在 1.7.0 版之後也發布了對於 ASP.NET WebForms 的支援,而 Glimpse.WebForms 可以說是原本 ASP.NET Trace 功能的進階加強版,所能提供的資訊與內容是更多樣且更為清晰。
但是在使用 ASP.NET WebForms + ADO.NET 的情況下,如果使用 Glimpse 而沒有經過任何調整的處理,那麼在 SQL Tab 是不會有任何作用與資訊,所以這一篇就來說明要怎麼調整讓 Glimpse 的 SQL Tab 可以顯示頁面執行 ADO.NET 存取資料的 SQL Command 內容。
在 twMVC #15 的這一場研討會裡,我主講「開發的效能與效率」這一個主題,裡面所提到的 MiniProfiler 是我一直相當推薦給大家在開發的時候來使用,除了 ASP.NET MVC with Entity Framework 的專案可使用之外,甚至是 ASP.NET WebForms with Entity Framework 的專案也一樣可以使用,但如果在資料存取並非使用 Entity Framework 而是使用傳統的 ADO.NET 時應該怎麼設定與修改呢?
在這一篇裡將會以 ASP.NET WebForms + ADO.NET + MiniProfiler 3 的使用情境做使用與設定的說明。
LINQ Insight 這個工具在 2012 年發布之後就已經有在關注,只不過一開始的功能並不是很好用,而且沒有讓我感覺到能帶給我在開發上有任何太大的幫助,所以最後就沒有用在開發上。
不久前閒晃到 devart 網站,我一直有使用 SQL Complete 與 Code Compare 這兩個工具,所以有時會上去下載新版的更新檔案,然後就發現到 LINQ Insight 已經更新到 3.2 版,而且介面與功能有了一些改變,於是就下載試用版來試試看,在試用過之後,雖然 LINQ Insight 還是有部份功能無法達成的情況,但整體來說是個不錯的輔助開發工具,這邊就向大家做個簡單的介紹。
MiniProfiler 在今年四月發佈了 3.0 的版本,不過新版本還不太穩定,一直到了這個月所發佈的 3.1.0 這個版本才算穩定,而 3.x 與之前的版本在設定上有些差異,並不是變得比較複雜,反而是更為簡單,而且因應不同 EF 版本與不同的資料存取,在設定上會有所不同,哪些版本應該做什麼樣的設定,在 MiniProfiler 的官網上都有做說明,所以只要照著官網上的說明就可以了。
在 2014-06-14 所舉辦的 twMVC #15 研討會,我所主講的內容裡就有說明 MiniProfiler 的使用,那麼在這裡使用文字與圖片的方式做個簡單的說明。
在去年 twMVC 有辦過一場 WorkShop 實戰營,當時是以 ASP.NET MVC 4 與使用 Visual Studio 2012 來做為課程的開發內容,時至今日,ASP.NET MVC 也已經發展到了 5.1.2,而 Visual Studio 2013 也是進入 Update 2,現在技術以及開發工具的發展越來越快,前不久的 Tech Ed North America 2014 也發表了 ASP.NET vNext 的內容,新的 ASP.NET 已經不再是你我所熟悉的那樣,新的 ASP.NET MVC 6 也有了不同的樣貌,不過別緊張,要到那一個階段還有一段時間,所以千萬別慌張。
這邊向各位介紹一門課程,讓想要跨入學習 ASP.NET MVC 技術的朋友藉由課程的引導,以循序漸進方式來學習 ASP.NET MVC 的開發。
前面幾篇有講到西元年轉換民國年格式字串的內容,因為我是使用 TaiwanCalendar 類別之後, 然後年份的地分直接使用 taiwanCalendar.GetYear(source) 的方式來取得,但這個地方的處理不能直接使用 source.Year - 1911 嗎?
當然你可以這麼用,而且你要清楚知道這麼用的原因,而且要確保開發團隊的成員都知道這麼做的原因,甚至於你也要確保日後接手維護的開發人員也能夠知道,不然哪天出現一個天真純潔的開發人員看到這樣的程式,就會想說為何不用 source.AddYears(-1911) 來處理呢?程式不是更加簡潔、漂亮嗎?當出現這樣的狀況時,抓蟲、找問題又將會是一場令人惱怒的過程。
在台灣使用 .NET Framework C# 的開發人員對於這樣的轉換都應該內化為基本操作知識,也就是當有西元年轉為民國年的需求時,都要能夠馬上使用正確的方式來取得正確的資料內容,而並不是直接使用減去 1911 的方式來結案。
為什麼呢?
你使用任何一個閏年(台灣每次總統大選年、夏季奧運舉辦年、美國總統就職的那一年)去取得 2 月 29 日,然後直接用減去 1911 的方式來看結果,我想大部分的人就會知道答案了,如果你還是不懂,那就繼續看下去。
在上一篇「AutoMapper Custom Type Converters 的應用 - 將所有日期資料轉換為民國年格式」為各位說明了怎麼將取出資料裡的西元年日期型別資料使用 Custom Type Converter 轉換為民國年格式字串,因為是使用了 Type Converter 所以會統一處理指定型別的轉換,那如果我們不想要統一處理而是想要指定某個欄位做轉換,而其他的日期欄位不需要做轉換,這樣的情況就可以使用 Custom Value Resolvers 來做處理。
之前曾經寫過一篇文章說明 Custom Value Resolvers「AutoMapper - Complex Type 使用 Custom value resolvers 設定屬性轉換」,不過使用的情況與這一次的要說明的並不相同。