.NET Walker

這一篇介紹 Bootstrap File Input 這個套件，之所以會被歸類到asp.net Web開發框架系列，是因為整個套件和我們採用asp.net走SPA架構(不管是用WebForms或WebAPI)都非常的速配。 檔案上傳範例 首先我們有一個範例位於 Github ，如果你想要測試，下載這個範例後，基本上已經擁有所有你需要的檔案。請使用Visual Studio運行index.html這個檔案(對，沒錯，是pure html5)，執行起來的畫面像是底下這樣: 這個套件精彩的地方是上傳預覽畫面，你會看到上圖中，它除了支援中文、多檔上傳、非同步上傳，還支援圖片預覽、Mp3檔案甚至可以撥放，會不會太誇張了點? 是的，人家就是支援…更不用說UI的部分很有誠意的原生支援正體中文(包含zh-TW的多國語言js)這也是我們使用此套件的原因之一。 如何使用 整個套件的使用可以完全採用AJAX方式(當然也支援傳統的submit/postback)，搭配我們的SPA架構非常之合拍，也因此，你在運行該範例的時候，會發現只需要執行index.html即可(當然伺服器端接收檔案的部分還是需要Server Code，這我們後面介紹ReceieveFile.aspx的時候再說明)。 如果你看index.html，會發現程式碼如下: 我們先看55行的部分，這是定義一個Input標記，其中的multiple意味著支援多檔上傳，data-show-preview="true"則是支援顯示預覽視窗。當然這些設定都可以在後面透過js來更動。 而66行javaScript所呼叫到32行的setupFileUploadBox()，就是進行相關的設定，其中language: 'zh-TW' 指定了多語UI採用中文(請留意這也是我們在19行引用了locales/zh-TW.js的原因)，而後面幾個參數應該不需要太多解釋，showUpload是顯示上傳按鈕，uploadAsync說明了採用非同步上傳，maxFileCount指定了檔案上傳上限。 比較重要的是uploadUrl，這個參數指定了非同步檔案上傳的接收位置，由於這個範例採用WebForms，因此我們指定ReceieveFile.aspx，這部分我們待會後面介紹。(我覺得熟悉WebAPI的開發人...

先前我們分別討論過了使用Vue.js進行 表格資料渲染 以及渲染時 動態產生的功能性按鈕 之後，接著，我們來看Vue.js在表單上的資料繫結。 範例依舊是我們先前使用的那個: source code : https://github.com/isdaviddong/AspNetWithVueBinding 測試網址: http://ex20170110-aspnetwithvuebinding.azurewebsites.net/   (如果該網站被我不小心殺掉，請 FB訊息 提醒我，網站裡面的資料由於是共用的，可能會被玩壞或出現詭異的內容，一概與本人無關XD ) 看過了先前的介紹之後，你大概已經知道，動態產生的『編輯』鈕: 該按鈕會在用戶點選時，將畫面導入到AddNewOrUpdate.html這個頁面，進行編輯的動作，而首頁上的新增鈕，其實也是將網頁導入到AddNewOrUpdate.html這個頁面。唯一的差異在，如果是按下編輯鈕，該筆紀錄的guid會被帶入: 這個動作怎麼實現的，答案在我們先前進行動態Button渲染時候的Vue instance中的edit method: 這使得如果用戶按下的是新增鈕，AddNewOrUpdate.html這個頁面將不會收到QueryString，若用戶按下的是編輯鈕，則是用戶欲編輯的record的guid。 因此，我們就不難理解AddNewOrUpdate.html這個頁面一開始進入後的javaScript code，就是判斷是否有Guid: 我們把guid保留在12行的變數中，30行之後的document ready，則是判斷是否有guid，如果有，則在36行呼叫LoadData，把該筆資料載入。而不管有沒有資料，31行的SetBinding都會把UI上的HTML表單與記憶中的vd_StudentRec做繫結: 所以你不難猜到，LoadData這個function，在從遠端載入完資料之後，會放到哪一個地方? (別往下看，先想一下…) 答案當然是: 記憶體中的vd_StudentRec，沒錯。其實，上面這段程式碼是為了說明，否則在實務上你把回傳的資料result.Data，直接放入Vue.js的instance就好(vm_student.rec=result.Data)，因為vm_student.rec...

接續著 上一篇 ，我們這次拿這個WebAPI + Vue.js 的 CRUD範例 繼續討論。讀者可以點選 這邊 ，看看這個範例的實際執行狀況。(如果該網站被我不小心殺掉，請 FB訊息 提醒我，網站裡面的資料由於是共用的，可能會被玩壞或出現詭異的內容，一概與本人無關XD ) 這個網站的主畫面如下: 上一篇 我們大致上說過，這些資料是透過伺服器端以JSON格式傳到前端，並且透過Vue.js的template rendering機制動態顯示出來的。 但我們沒有談到，上圖中每一個row最左邊的編輯/刪除鈕，是怎麼實現的，我們這一篇就來介紹這個部分。 在HTML Tempalte中加上功能按鈕 先前我們看過的HTML樣板，要加上Button很容易，但Button要有對應的功能，則需要透過v-on:click 指令: 你會發現，上面的第4,5兩行，多了兩個Button，就是編輯和刪除鈕，分別是呼叫到edit和remove這兩個javascript function，並且傳入item作為參數，還記得嗎?這個item就是第2行v-for裡面的item in items的那個item，也就是伺服器端傳來的資料集合中的一筆資料。 因此，當用戶點選這兩個Button，實際上會執行到的，就是Vue.js的vm裡面所定義的methods(位於12-22行) : 這個在Vue.js稱之為 方法事件處理器 。留意上述程式碼的第12-22行，其中的edit、remove，就是按下Vue.js動態渲染出的Button時，會觸發的JavaScript Functions(Methods)，由於帶入的參數是item，也就是按下哪一筆資料的Button，就把該筆資料作為參數帶入。因此function裡面的程式碼就不難理解了。 remove method的14-16行會出現confirm(…)視窗，如果用戶確認刪除，則調用Remove(item)這個我們自己寫的JavaScript Function。而19行則是edit method，功能是redirect網頁到AddNewOrUpdate.html，並帶入資料record的Guid作為QueryString參數(由於AddNewOrUpdate.html這個網頁因為同時包含新增與修改兩種功能，比較複雜我們改天討論)。 我們先看14-...

前面 寫過了在asp.net WebForms環境下使用Vue.js做DataBinding/UI Template Rendering，這一篇我們把焦點轉回WebAPI的版本。 如果使用前面介紹過的 寫法 ，以WebAPI搭配Vue.js進行SPA Web應用程式開發，那前端的頁面可以是很單純的pure HTML，例如: 和 先前 介紹過的一樣，UI上進行Binding的部分只有60-90這一個區段，透過Vue.js的繫結語法{{item.xxxx}}把每一個屬性的值填入UI，而促使這個Binding生效的js程式碼位於14-21行，也就是SetBinding()這個javascript function。這個SetBinding()建立了vm_StudentInfo這個Vue instance，把HTML UI上的tableBody與vd_StudentInfo這個記憶體物件做了繫結。 因此，每當vm_StudentInfo的items屬性被更新時，Vue就會拿vd_StudentInfo中的數據來更新tableBody區塊中的UI。 而底下這段程式碼(24-31行)則是binding_StudentInfo的items屬性被更新的時機: 也就是畫面上的『Get Data』Button被按下去的時候。會透過ExecuteAPI呼叫伺服器端的WebAPI，因此底下的程式碼被執行(還記得這一大段WebAPI程式碼在幹嘛? 我們曾經在 先前 詳細的介紹過): 是面這段WebAPI身為服務層，任務就是動態載入並執行相對應的BO，因此進而運行到BO.Health.GetData這個GetData Method: 執行後的結果List<StudentInfo>會透過JSON回傳到前端，被透過Vue 的DataBinding(Template Rendering)機制顯示於螢幕上: 同樣的，按下上圖中的『清空』鈕之後畫面會被清空的原因也很好理解，我們只是把繫結物件的items屬性清空: 因為vm_StudentInfo.items 被設為 undefined(或其他空值)，則頁面上顯示的資料就被清空了，就是這麼簡單。 其他的部分我們在 上一篇 介紹過囉…(先前針對程式碼相關更完整的解釋請參考 這裡 ) source code : https:...

弱水三千，為何只取Vue.js? 一直以來，我覺得大部分的開發技術其實也是一種工具，也有生命週期。既然是一種工具，那開發技術當然不能只是拿來 學習 ，而應該是拿來 使用 的。最近幾年，隨著開發技術的生命週期越來越短，不免讓人開始猶豫該如何選擇。如果你慢慢發現，學習某一門技術的時間並沒有遠低於使用它的時間，那就得回頭重新評估這個工具了… 但，千萬別誤會，我不是叫大家不要花時間去進修，或是減少學習的時間。這年頭，我們比過去以前任何一個時代都需要 時時刻刻 學習。但，正因為我們的時間越來越珍貴，越來越難以過去的大量快速學習來面對技術的變遷，因為現在不管學得再快，也無法趕上變化的腳步… 莫名其妙講了一堆，好像跟這個主題無關? 非也，我想說的是，最近幾年我在專案中選擇的工具(開發技術)時，都盡可能以不用花太多學習時間的為主。因為工具(技術或框架)最終的目的是幫你節省時間用的，倘若學習成本太高，可能會本末倒置。而這個理由，也恰巧是我們選擇Vue.js作為前端開發框架的原因。 當過去幾年我們在.net環境嘗試建構一個適當的開發架構時，三層式的SPA對我們來說是個能同時滿足行動裝置、Web、以及桌面應用的理想選擇，而要採用何者搭配SPA作為Web前端開發套件呢? 最終，我們選擇了Vue.js。 理由? 它的程式碼很簡潔，非常輕量級，執行速度也算快，一點都不讓人覺得累贅。 它很好學，還有中文的文件(唯一的遺憾是簡體)，對於已經有前後端程式碼分離、SPA基本概念的人，用起來跟喝水差不多。 它在資料繫結這個部份的做法非常直覺，MVVM概念的實現很接近以前XAML的作法，同時，它採用的標記語法很簡單，也極不容易破壞HTML版面，和設計師(designer)很好合作。 以上是最主要的這幾點。 Demo的前置準備 我們前面說過Vue.js學起來很簡單，因此我們也不用談什麼初階進階的東西。待會的Demo就直接從伺服器端把一組資料傳到前端，然後透過Vue.js做一個Binding(Template Rendering)，以表格的方式把從伺服器端傳來的JSON資料呈現出來。 (若需要完整的CRUD請參考本文最後) 如果你想跟我一起 hands-on 一下，請依照底下的操作步驟做好前置準備，別忘了，我們用的是 SPA架構 ，把以前你熟悉的asp.net WebForms或as...

你沒聽錯，事實上asp.net WebForms也能走SPA(Single Page Application)的開發架構，並且跟在前端的Bootstrap與Vue.js框架搭配得很好。 技術的使用存乎一心 記得曾經對學員說過，不管你用哪一種開發方式，只要對開發技術有足夠的熟悉，並且瞭解基本原理與前因後果(再說一次，學習時， 為何 永遠比 如何 重要)，那實在無需追逐潮流，你依舊可以在技術變遷中掌握到重點。 曾經聽過有些開發人員從WebForms轉換到MVC走了一條坎坷的路，並且轉換的理由很是讓人莞爾，這邊略過不提。但我想說的是， asp.net的MVC和WebForms走的是兩條截然不同的架構路徑，兩者並沒有取代性的問題，千萬別誤以為MVC主要目的就是用來取代WebForms用的 。 順帶一提，那我認為什麼是真的有取代性的? 舉個例子，物件導向程式設計幾乎取代了結構化程式設計；資料庫存取的ORM技術，幾乎取代了ADO.NET等非ORM的資料存取技術；C#中的Linq取代了傳統的物件查找方式。這些，則是有取代性的… 所以，這一路上曾經聽過有些開發人員從WebForm轉換到MVC卻走了不少冤枉路， 然後換到MVC之後卻用和傳統ASP一樣的思維在開發系統，這樣換比不換更慘 。 如何在asp.net WebForms中實現SPA? 警語 : 接下來的內容很是驚悚，如果你對於asp.net WebForm或是MVC的『標準寫法』有著異於常人的堅持，不容妥協，那請自行斟酌，小心閱讀這篇。 還記得我們先前曾經說過的嗎？SPA對我們團隊來說的價值是『 沒有任何從伺服器端Render HTML到前端的行為 』，這麼做有哪些好處，在 前面 我們已經多次的提到過。 但整個WebForms的架構根本就是從伺服器端Render一堆的HTML到前端啊，這架構怎麼會符合SPA呢? 是的，這沒辦法，因為WebForms生來就不是走SPA路線的，在WebForms誕生的那個年代，根本還沒有SPA的影子。整個WebForms的行為都是在模擬傳統的Windows物件導向程式設計，因此任何的WebControls，舉凡Button、InputBox、DropdownList…全都是透過後端的HTML Render Engine動態產生的。 這導致，如果你用了任何WebContro...

前面 我們談過了非技術的背景原因之後，我們在這篇會正式開始跟各位介紹我這幾年在團隊中最常使用的開發架構。在大部分(超過九成五)的Web開發情境下，最近幾年我們多半採用SPA(Single Page Application)架構。這邊我們先定義一件事情，有些人覺得(認定)SPA就一定只有一個html page，整個應用程式就都在這個page當中運行，所有的功能都在這個頁面上呈現，所以也沒有換頁這件事，但，對我們來說並不是這樣的。 SPA概念在.NET或非.NET陣營上都有著不同的定義，但對於我們團隊而言，其重點在於『 沒有從伺服器端動態Render HTML到前端 』的這個動作，伺服器端與前端Browser之間的交互，只有幾個行為: 下載靜態HTML Pages(大多時候都不只一頁) Client(Browser)與Server(WebAPI)之間的Http Call與JSON傳遞 前端頁面也幾乎沒有Form Submit這個動作，取而代之的是AJAX非同步呼叫。 that’s all. 這樣的規範(你要說是限制也行)讓開發架構變得非常單純，應用程式很自然地分成了三層: Presentation Layer(view)，採用HTML+javaScript ， 運行於用戶端Browser Service Layer，採用asp.net WebAPI或PageMethods，運行於伺服器端IIS Business Logic Layer，採用C#寫成的class，運行於伺服器端Application Server或IIS(和Service Layer佈署在一起) 為何不用任何『從伺服器端動態Render HTML到前端』的機制? 伺服器端只對前端傳遞JSON與靜態HTML(而非透過C#程式碼動態生成的HTML)，這是一種限制，但這個限制利大於弊，所有透過伺服器端往前端Render HTML的技術(ASP、PHP、ASP.NET WebForms、ASP.NET MVC View)，一不小心都很容造成相依性、並且導致重用性降低，因為開發人員會忍不住把Business Logic寫在其實是Render View的展示層程式碼中(如果你曾經在MVC的Controller或是WebForm的Page裡面寫存取資料庫或撰寫運算的code，那就是了)。你很難...

講技術之前，先讓我說說最近發生的幾件事情… 這時代沒有什麼趨勢好說的… 前些日子，我在某個研討會當中，碰到一位學員，他在上課前找到了我，搶先問我先前提過要開的架構設計課程，最近一次何時會開呢? 我很高興他對這個課程有興趣，但是卻只能黯然地跟他說，今年實在不一定有空了。 除了時間的因素之外，其實也因為有另一個顧慮，就是這幾年的資訊科技變化實在不小，在頻繁的變化當中，要建構出相對穩定的架構確實不易，也因為有感於此，在這場研討會中，我很猶豫的要不要提更多我對於這幾年技術變化自己的看法。 別忘了技術的最終目的永遠是應用 前陣子有位大神問了我一個問題，當然，大神的功力都是很強的，問的問題當然也讓人無法小覷，所以沒多久我就投降了，我直接告訴他我不知道。原因很簡單，因為我沒用過，而沒用過最近也不會用到的東西，我大概不太會去碰。因為『吾生也有涯，而知也無涯。以有涯隨無涯，殆已。』數千年前，莊子就知道這件事了，我又何必勉強呢? 得知道，所有的技術都是為了應用，學技術本身當然是愉快的，如果學技術本身就可以賺錢，那何樂而不為?然而非也，技術能用到對的地方，才能賺錢。不是說賺錢很重要，而是玩物喪志恐怕也不是成年人可以一直走的路，也因此，誠實的面對自己的知與不知，選擇在有限的時間內，將有需要的技術盡快地掌握，是我這幾年來學習的原則。 捷徑只有一條 我曾經聽一位老師說過，在專案管理當中，只有一個方法能立即加快速度，那就是減少浪費。加人、進修、提升能力、凝聚向心力…都很可能治標不只本，再說一次， 只有一條路可以真正的加速，那就是減少浪費 。其實，學習也是。請原諒我這麼說，但這年頭很多的大學，四年的時間基本上是浪費了，你常常看到為何有些年輕人不需要念大學就可以有所成就，因為，雖然學習是重要的，但依照別人排好的時間表以及重點來學習，它不是為你量身訂做的，對學習者來說當然弊多於利。要知道，現行台灣的教育制度也不是培養人才的最佳解決方案。但沒辦法，對於一般人來說，恐怕這是唯一的路，所以莘莘學子跟著大家一起念大學，之後跟著大家一起找 不到 工作。如果你不想做『一般人』，就得要想辦法減少浪費，從學習到專案，都是如此。 新舊從來都不是問題 我有一個朋友，其實算是前輩了，他公司還是用Delphi開發系統。幾年前第一次聽到的時候我很是訝異，我不是訝異Delphi還活著，它活著我知道，但在這個技術一個...