上一次的練習真的是從零開始，看完一門線上課程加上一點GOOGLE就開始動手做了，做的過程中發現問題才再回頭翻書找資料，而且也只做完後台而已，在寫完三篇心得後，我又花了大概兩天左右的時間把題目重新做了一次，這一次採用的是比較中規中矩的做法，每一張資料表相關的控制器，模型及視圖都獨立開來做，光路由就寫了46條路由，模型九個，控制器11個，視圖10個，中介層1個，服務供應者1個，整個做下來最花時間的地方是在視圖上，因為後台的視圖我還是嘗試要用一個檔案來搞定，這使得語法上變得有點複雜，下一次簡化應該會從這方面著手，就像我在之前的心得中提到的，用框架來做開發，就不要再擔心檔案太多的問題了。

重做一次的心得是框架可以幫助讓整個網站的架構比較清楚，負責邏輯的和負責資料庫的以及負責顯示的，都切得乾乾淨淨的，不像以前原生寫法那樣一個檔案中同時有PHP又有HTML又有JS，要查問題時很花時間，要修改時也要很小心；但是框架並不完全那麼美好，比如我在session和登入驗證上就花了點時間去研究，才能做出我想要的結果來，比如登入驗證的功能，內建的機制雖然很方便，但如果只依靠內建的來實踐功能，很多事反而會受到限制，題目要求的登入很簡單，不需要太多驗證，我想跳過內建的機制，但沒有相關的資訊，網路上找到的全是告訴你登入很簡單，內建就有，你CODE都不用寫就做好了，但我要的是不同的驗證方式，卻沒有相關的資料可以參考，所以使用框架在我目前的程度來看，一點也不輕鬆；我認為框架在後續的維護上是有一定價值的，但像檢定或比賽之類的場合，框架不一定有優勢，除非刻意的去忽視這些規範，用硬幹的方式在框架內做一些扭曲的應用，這樣的話的確能在速度上取得好處，比如今年的全國技能競賽有一個題目的資料庫查詢語法，用框架反而做不出來，最後大家都是用原生的查詢語法下去做。

在這兩次的試解中，其實我花在找資料和看畫的時間上幾乎是解題時間的兩倍，原因是網路上找到的東西大多只是重覆官方提供的範例再解釋一次而己，如果我想做的功能和官方提供的不太一樣，就幾乎找不到解答，我只能自己想辦法去試出來，所以我覺得學習成本上並沒有比較低，而且還得對程式語言有一定基礎的人，才有辦法從框架的官方說明或原始碼中去找到問題，然後完全的掌控整個框架工具的使用，像是session的使用，之前看的課程或資料都沒提到這塊，我想要做到的功能只能自己去試出來，即使是stackoverflow上的資訊有些也是文不對題。

後續的計畫是用laravel 把乙級四個題目做一篇，當成未來教學的教材之一，接下來是研究比較有歷史的Codeigniter，這樣的話，整個網頁乙級術科的解題就完整了。

這兩天雖然累，但還是花了點時間把一些其它的功能試了一下，主要是解決了後台的刪除資料功能，然後也解決了前台的blade include功能，不過這和原生的include並沒有太大差異，只不過解決了這個問題後，我才發現我必須整個解題重做，不然不但無法發揮laravel的特性，反而會讓整個解題的過程和體驗變糟了。

先前我說過blade在處理前端頁面時非常好用，但我錯了，今天在處理不同功能呼叫同一個VIEW時，卡了很久，主因在於我先前的做法還是照著我原生解題的邏輯，所以我把所有view會用到的功能都丟在一個陣列中，然後view會依照我route的設計來顯示需要的內容，因此我的view中使用了switch的方式來判斷要顯示的內容，雖然相比之前的4,500行少了很多，但是這招在後台有用，到了前台就沒用了，我得製作同樣的樣板來搭配前台的不同路由，雖然最終還是做得出來，但是我自己也感覺到這樣的開發方式是有問題的，因此我打算先停手目前的解題，重新做一次題目；先前我是因為對於拆多個檔案的管理方式感到恐懼，所以才會想要儘量把程式碼都集中在一個檔案來處理，不過到了laravel，觀念需要轉一下，所謂檔案就是類別或物件，不再需要像原生開發那樣，擔心檔案一多，連結和導向的管理變得混亂；在laravel中，一個Controller中己經把常用的幾種function都建好，應該專注在單一功能的實踐上就好了，而不需要去擔心檔案的從屬關係，而View則是專注在佈局和內容的呈現上，而不需要擔心這次要顯示的功能是什麼，所以要額外判斷，然後特別去產生不一樣的內容；應該要更大擔的把需要的內容都物件化，讓laravel去管理路由和一些組件關係就好了。

最後在處理Session時，發現laravel的session管理有自己的一套模式，並非是延用PHP原生的管理方式，比如設定檔中有一項設定可以設定要不要在瀏灠器關閉時讓session立刻過期，照題目的要求，這個設定是要打開的，但從這個設定來看，就可以得知和原生的做法不同，原生的Session在關閉瀏灠器後，並不會馬上過期，但是當使用者再連上網站時，PHP會建立一個新的session，這是符合題目要求的，不關閉瀏灠器的狀況下，瀏灠次數不會更新，關閉瀏灠器後再連上才會更新瀏灠次數的要求；但是laravel預設會記住使用者的連線紀錄，所以就算關閉瀏灠器，只要session還沒過期，再次連上網站還是會有效。

另一個問題是我在處理前端時，其實有不少的值是共用的，但是照我原本的寫法，我得在每次要建構View時，都去再撈一次資料，然後再從各個Controller丟去View做顯示，做到這我也自己知道做錯了，這和原生解題時寫一個base.php，然後每個頁面都要先include這個檔案沒什麼兩樣，等於是在瀏灠各頁面時都要去資料庫再撈一次資料一樣的意思，後來終於找到laravel有一個service povider的功能可以使用，白話點說，就是可以利用這個機制來建立整個網站的全域變數，像是標題圖片的位置，瀏灠次數，頁尾版權，前台的選單及校園映象圖片這些在很多畫面會共同用到的資訊，可以建一個全域變數來放著，然後View就可以直接把變數拿來使用，然後各個Controller在建構View時，只要專注在提供自己專有的資料就好了，不需要再去把共同的資料再撈一次。

總結這一周研究Laravel框架的心得就是的確可以在開發上簡化不少工夫，但這過程並不如許多推廣者所說的那樣無痛而美好，就我個人來說，單看網路上的教學都是功能單一的內容，所以看起來好象真的很容易，但是像我這樣拿一個完整的網站範例來練功一下，就會發現還有很多要去了解和深入的地方，再加上整個開發流程和觀念也不同，熟悉機制到觀念轉換，一個月的學習時間應該是跑不了的。

今天不用上課，所以利用半天時間繼續把第一題解下去，今天主要是解決更新資料的問題，先前在用原生的PHP解題時，我是直接用一個表單POST所有資料到一個專門處理資料更新的API去做多筆資料更新的動作，但是在laravel上，預設是一次只能更新一筆資料，另一個問題是Route的設計會和原本的新增路由衝突到，這兩個問題花了一些時間研究，搞定後，其實後台卜就等於做完了。

先說路由的問題，由於Laravel在一開始設計時就傾向於REST的精神，所以在Route上有提供的PUT/PATCH/Delete的方式，但是目前大多數的瀏灠器只有提供GET和POST的方式，所以如果要在表單上實踐其它的HTTP動作，應該是要以AJAX的方式來實踐，不過，Laravel在這部份有提供了一個欺騙的方式，並且也已經做了路由的對應，因此只要在表單上做一個隱藏欄位，並傳送所要執行的動作名稱，接卜來要設定好動作的的路由，然後對應到Controller的update方法，就可以做資料的更新了；

再來是說更新資料的問題，內建提供的update方法預設是必須帶id的，而且一次只能更新一筆資料，所以我改了原本的方法，把id拿掉，然後在表單上放了一個隱藏的欄位當成id，接下來就是用迴圈去把表單資料一筆一筆做更新；雖然可以完成我預期的大量資料更新的工作，不過在了解了laravel的背後機制後，我認為這樣的做法可能不太有效率，所以之後考慮改用別的做法來實踐，但是做到這裏，我己經掌握laravel一些可以自訂及修改的部份了。

最後我試著撈取資料丟回前端的blade去顯示包括標題圖片，進站人數，頁尾版權宣告這些內容，看起來都運作良好，接下來會再研究一下session，cookie及前端js 的整合，這樣應該拿來解其它題都就沒什麼問題了。

目前的階段在使用Laravel上己經沒有什麼大問題了，不過這類框架在使用上的確和原生PHP的觀念上有很大的不同，比如我現在把後台的所有功能顯示的資料都放在一個Controller中去實踐，包括View的樣版也是一個檔案搞定全部的功能，但這個做法和Laravel強調的MVC是不符合的，實際的做法應該把每個功能都獨立一組MVC出去，這樣才方便日後的維護和分工；BUT，我這樣實驗的目的是考量到如果要拿Laravel來做競賽或檢定時，每一個功能都要MVC的話 ，那光開完相關檔案就要去掉不少時間了，所以這部份只是要驗證說Laravel的彈性可以做到什麼桯度，是否可以依照目的不同，而有相應的調整，後來我也在網路上找到一些文章在討論進階的功能管理方式，可以把MVC的架構再做得更精細，不過這要等日後有機會再研究了。

花了兩天的時間研究了一下laravel的實作，如果只是照著書上說的或是線上課程的範例，大多都能執行成功，但這沒什麼，畢竟只是走別人走過的路；所以自己打算找些題材來實作練習，第一個想到的就是拿網頁設計乙級的題目來試刀，從頁面blade語法開始研究到後來的Model及Controller的運作，兩天下來只完成了後台的一半功能，過兩天有空再來完成剩下的，不過這邊先紀錄一下心得，免得到時要接上時又忘了。

單就前端頁面的建構來說，使用blade樣板語法後，前端頁面的建構變得非常簡單而且好維護，原本後台的各個功能頁面我是採用switch case的做法，直接複製各個功能的 html碼，再把一些文字做替換，雖然複製貼上是很簡單的工作，但是在修改各畫面的欄位名稱及文字時，不免還是會有遺漏或打錯的狀況，使用blade後，欄位名稱改成用變數的方式來傳送，只要用語法做好一份模型，接下來就是由Controller來控制要傳什麼功能的欄位名稱過來，樣板會自動生成對應的完整HTML語法，原本要4,5百行的檔案，一下縮到一百行左右而己。

資料模型是我目前覺得比較麻煩的地方，也是今天花最多時間研究的地方，單純就ORM的操作來說，的確可以簡化原本的SQL語法操作，甚至比我先前的先寫function的做法還來得快，但目前發現的缺點是一張資料表只能對應一個Model，所以第一題會用到九張資料表就得九個Ｍodel，然後再對應九個Controller來操作資料的CRUD，當然也得設定至少九個相應的Route來管理各項動作，雖然最後只是複製貼上再改一下資料表名就可以，但是採用框架就是為了做到DRY(Don’t Repeat Yourself)，這讓我不得不考慮是否改成直接用DB類別來操作SQL語法會比較快一些。

laravel在table migration的做法和之前習慣的做法不一樣，所以這部份也是要花時間研究，以往都是直接在資料庫或透過phpmyadmin直接建表完成後再來寫程式的，但是laravel是把整個資料表的操作都拉回到框架裏來操作，這部份是考量到團隊工作時，需要有個資料表修改的紀錄做為開發的參考，另一方面也是為了同步團隊的資料表結構而做的設計。

估計再花個一天時間可以把後端的部份全部做完，前端的部份目前看起來不難，後面會有點挑戰的地方應該是Session的使用及laravel驗證機制的操作。

做到目前的心得是採用框架來做解題，並不一定比較快速，而且開發觀念也得轉個彎，但如果是花點時間練熟悉的話，因為整體的程式碼數量是減少很多的，加上錯誤發生機會降低非常多，所以如果練習的強度夠高，整體速度還是可以加快不少的；後面的計畫是在年底前把網頁乙級四個題目都用laravel做過至少一次，然後找出最有效率的解法來。

上個月花了一筆錢去買了線上課程來看laravel的教學，不過內容只有一開始的觀念部份比較受用，後面在談實作時，感覺講師完全忽略了學員的程度，速度一下衝上高速公路，後來自己又翻找了一些資料，總算了解一些框架使用上的問題。

這個月開始，我結束了手上的選手培訓工作，剩一個職訓班的課程，所以有時間開始來研究新東西，而我預計明後年的網頁設計乙級有很大的機會會改題目或加入新的函式庫，所以打算先來研究laravel，之後再回頭去研究CI(因為目前函式庫提供的是舊版的CI，我覺得研究的價值不如直接寫原生PHP)。

之前在看了許多的laravel介紹都特別強調要先安裝composer，之後再安裝laravel，我對這點一直很有疑惑，今天試了一下總算有所了解，composer的作用主要是在解決套件相依的問題，因為laravel使用了不少套件來輔助，所以如果不安裝composer，那麼就要自己去把一堆相依套件找出來，並做好相關的設定，laravel才會正常工作；我一開始直接下載laravel放到目錄中的確無法工作，後來沒辦法；裝了composer後，觀察變化，發現主要是多了vendor這個目錄，這個目錄的全部檔案大概29mb多，而laravel的目錄結構及原本的檔案加起來不到1mb；下載完vendor裏的所有套件後，測試了一下，還是無法work，原因是laravel的運作需要在.env檔中放一組key，所以利用artisan 來產生一組key就可以運作了，除了自己開apache來測試外，也可以用arrtisan自帶的serve指令來建一個臨時的網頁伺服器；最後我做了一個測試，把裝好相依套件的專案目錄複製一份起來，改個目錄名，接著把composer移除，然後再試試看laravel能不能正常執行，結論是可以執行；所以說沒有composer也是可以執行laravel的，但是如果使用的專案會利用到其他的套件或是專案本身就是用來開發套件的，那可能還是需要安裝composer來協助做套件的管理；否則，composer在laravel的定位主要就是一開始做版本相依套件安裝時有用而己；當然，composer的作用並不只是做套件安裝檢查這麼簡單而已，其強大的功能在當代的PHP開發上有著相當的地位，所以Laravel才會把composer納進來成為開發環境的建議項目之一，不過composer的研究我是打算之後自己在做side project時再來慢慢研究。

我想測試不用composer的原因不是吃飽沒事幹，而是因為之前的技能競賽有提供laravel，但我很好奇現場沒有網路的狀況下，是要怎麼運作？現在自己試一次就比較清楚怎麼回事了，考場應該也是把整包己經裝好各式套件的Laravel提供給考生，所以就算沒有網路，沒有composer，也是可以在離線的狀況下直接在本機端進行開發的工作。

在確定了Laravel可以運作後，我做的第一個實驗就是把網頁乙級的第一題版型先納進來試試看，相較於以前使用檔案的方式來開發網站，目前市面上的框架都是用”路由(Route)”的方式來開發，也就是MVC的開發方式，不過我只是為了先確定可以把靜態頁面先納入，所以我把css及js搬到public目錄下後，依照Laravel的規範，把版型檔案改成*.blade.php的樣版檔案，放在resource\view中，接著在routes\wep.php中寫四個Route去對應四個樣版檔案，這麼一來，以前都是用/*.php的方式來link檔案，使用框架後，會改成用/*的方式來訪問需要的服務，開發觀念上會大大的不同。

使用Laravel來套版型