排除公告

嗨!遊客

歡迎您的到來喔!第一次來此嗎?

如有任何問題,還請到 建言/問題

教學 Laravel簡單易懂的教學。作者:小魚

本帖由 yoching2019-11-29 發佈。版面名稱:Laravel

  1. yoching

    yoching 站務人員
    管理成員

    註冊:
    2016-10-01
    文章:
    40
    讚:
    3
    00:Laravel從入門到放棄…原生PHP-前言

    既然是從入門到放棄,
    那第一天教人入門,
    第二天勸人放棄,
    第三天就可以結案了...
    (等等, 說好的30天呢?)

    --
    以上內容,純屬虛構,
    如有雷同,純屬巧合。

    ---------- 我是可愛的分隔線 ----------

    這次要講的是PHP最近很流行的框架-Laravel,
    這幾年很流行MVC和MVVM,
    Laravel本身可以實現PHP MVC,
    讓程式設計師們可以比較容易以MVC的架構來完成PHP的專案,

    至於什麼是MVC呢?
    這部分之前的鐵人賽已經有提過,
    有興趣的可以看 [Day 01] 什麼是MVC?能吃嗎?

    之前比較少去了解MVVM的架構,
    這次搭著鐵人賽的順風車,
    就花點時間做點認識,

    這幾年很流行將使用者介面、商業邏輯與資料分離
    常見的有MVC、MVP、MVVM等架構,

    MVVM簡介
    MVVM是Model-View-ViewModel的縮寫,
    透過將使用者介面(View)、商業邏輯(ViewModel)與資料(Model)分離的設計模式,
    達到降低介面設計與程式設計彼此的影響,
    進而使各別的開發人員能專注於本身的設計,
    並更加方便測試與整合.

    View: 使用者介面區塊,介面設計人員只需要透過Expression Blend工具進行編輯,並利用Binding的方式與ViewModel進行溝通連結。
    ViewModel 商業邏輯區塊,程式設計人員可在此實作商業邏輯,並透過公開的屬性提供給View進行Binding使用。
    Model 資料區塊,用以描述資料實體的簡單類別,也可在此實作商業邏輯及資料庫存取相關功能。

    MVVM設計架構中,
    上層的物件可以向下存取,
    但是下層的物件並不會知道上層物件,
    透過此原則得以做到乾淨的分層與鬆散耦合.

    View與Model中介點
    ViewModel介於View與Model中間,在架構上可視為兩個區塊
    真實UI(View)與商業邏輯(ViewModel)區塊,此時ViewModel作為實作真實UI操作後所觸發的商業邏輯。
    虛擬UI(ViewModel)與資料(Model)區塊,此時ViewModel作為模擬UI的操作向Model進行資料處理。
    [​IMG]

    View與ViewModel溝通方式
    Data Binding: 介面元素與資料繫結,透過雙向Binding的方式,當資料有異動時會連動更新View與ViewModel相互繫結的資料內容。
    [​IMG]

    Command: 介面控制元件與程式碼繫結,透過在ViewModel實作ICommand的介面,提供給View繫結的控制元件觸發呼叫使用。
    [​IMG]

    Behavior: Action與Trigger的綜合體,可使得原本不含Command屬性的控制元件也能達到相同的觸發效果,並可消除Command本身的操作限制,進而擴大Command的效益。
    [​IMG]

    MVVM優勢

    程式設計人員:

    • 程式的階層切分的更為乾淨簡潔
    • 相對減少透過程式進行與使用者介面互動
    • 可根據設計期/執行期決定不同資料來源
    • 程式撰寫可完全與使用者介面的控制項脫鉤,不須再撰寫Event handler
    • 可將設計重心著重在資料流與商業邏輯,不須花心思在使用者介面與流程
    介面設計人員:

    • 只須將心思著重在使用者介面的操作流程與呈現方式
    • 可藉由程式人員提供的設計期資料,製作更接近現實的使用者介面
    • 可輕鬆地透過Binding、Behavior就可以實作出使用者介面與控制元件的設定
    • 可輕鬆地透過Expression Blend工具完成使用者介面設計
    結論

    MVVM設計模式,在架構上能有效達到使用者介面(View)、商業邏輯(ViewModel)與資料(Model)的分離,使介面設計人員與程式設計人員能更有效率的各自開發、測試與整合。

    在上述的範例中,介面設計人員只需專注在View的使用者介面設計,程式設計人員則專注在ViewModel的商業邏輯實作與Model的資料處理,能各自開發與測試,最後再透過Binding的方式做整合,可有效提升團隊的工作效率,是相當不錯的分層設計模式。

    參考資料:
    淺談MVVM架構

    轉載:https://ithelp.ithome.com.tw/articles/10214909
    原著:小魚
     
  2. yoching

    yoching 站務人員
    管理成員

    註冊:
    2016-10-01
    文章:
    40
    讚:
    3
    [Day 01] 事前規劃 - 店商網站 功能分析

    今天是第二天了,
    今天是來勸大家放棄的,
    如果沒有
    堅持的信念,
    堅定的信仰,
    堅強的體魄...
    (為什麼要有堅強的體魄?
    你不知道當工程師是要爆肝的嗎?)
    最好還是放棄不要繼續往下看了...

    --
    以上內容,純屬虛構,
    如有雷同,純屬巧合。

    ---------- 請叫我可愛的分隔線 ----------

    我們這次會用Laravel來寫一個簡單的電商平台,
    真的非常簡單,
    拿出去要找買主絕對沒有人會買單的,

    這次主要著重在Laravel的部分,
    所以不會特別去處理CSS的部分,
    而且我的專長也是在後端而不是在前端,
    不會花那麼多時間去美化畫面.

    這次的功能主要會有 會員、商品、交易 三大項目,以下做一些簡單的說明

    會員

    • 會員註冊
      • 網站所有的商品要購買的話,都需要成為會員,所以在購買商品之前,必須先註冊為會員,才能購買商品。
      • 而且會員有管理者及一般會員的身分,不同的身分有不同的權限,目前限制需要管理者才可以管理商品資料。
    • 會員登入身分驗證
      在會員註冊後,必須要提供身分驗證,確認使用者的帳號密碼,正確的話才可以登入,進行購買消費。
    • 註冊E-mail通知
      • 當會員註冊成功後,會寄送註冊成功通知信
      • 通常電子報只會寄給E-mail成功驗證的會員,所以驗證E-mail是做會員系統必備的功能,為了簡化流程,目前先不做E-mail認證的功能,僅用E-mail通知註冊成功的訊息。
    商品

    • 建立商品
      僅有具有管理者身分的使用者才可以建立商品,商品必須填入「商品名稱」、「商品介紹」、「商品價格」、「商品剩餘數量」等相關資訊、商品建立完成後,再進行上架的動作。「」
    • 上傳商品圖片
      所有商品都可以上傳商品的封面照,所有封面照為了排版美觀,所有圖片都會被裁減成長寬比2:1的比例。
    • 商品清單
      當商品上架後,消費者可以在商品清單中看到所有可以購買的商品,當商品銷售一空時,會顯示「已完售」的狀態,無法購買。
    交易

    • 購買商品
      • 消費者購買商品時,選擇要購買的商品數量後,點選購買按鈕就可以直接購買,當不是會員時,則會將會員引導至註冊流程。
      • 購買時,我們會省略金流的步驟,簡化我們的購買流程。
    • 交易清單
      會員購買商品後,所有的消費紀錄都會記錄起來,以供會員隨時備查。
     
  3. yoching

    yoching 站務人員
    管理成員

    註冊:
    2016-10-01
    文章:
    40
    讚:
    3
    [Day 02] 事前規劃 - 資料表欄位規劃

    今天是第3天了,
    如果聽完前兩天的內容,
    您已經
    筋疲力盡,
    萬念俱灰,
    了無生趣...
    恭喜你,
    已經完成最後的放棄階段,
    後面的內容可以不用再看下去了...

    --
    以上內容,純屬虛構,
    如有雷同,純屬巧合。

    ---------- 挖系古錐的分隔線 ----------

    為了達到情境的需求,我們可以想像資料表需要儲存什麼樣的資料,才可以完成上述所提的需求,我們以最簡單的電子商務網站基本規劃,限制一次只能購買一樣商品,以這樣的情境,當作這次Laravel世界的試金石。

    使用者資料表

    說明 欄位名稱 欄位屬性
    會員編號 id integer
    E-mail email varchar(150)
    密碼 password varchar(60)
    帳號類型 type varchar(1)
    暱稱 nickname varchar(50)
    建立時間 created_at datetime
    更新時間 updated_at datetime



      • 會員編號
        • 欄位為主鍵(Primary Key)
        • auto increment自動增加編號
      • E-mail
        • 唯一鍵(Unique Key),同一個資料表不可重複出現
        • 當作會員登入帳號
        • 用於寄送電子郵件的信箱
      • 密碼
        • 用於驗證使用者輸入的密碼是否正確
        • 因為Laravel對密碼進行加密後,密碼長度固定為60,所以欄位長度必須設定為60
      • 帳號類型
        • 用於識別登入會員身分
          • A(Admin):管理者
          • G(General):一般會員
      • 暱稱
        • 用於顯示目前登入會員的名字
      • 建立時間
        • 資料建立時的時間,建立後此欄位資料永遠不會變
      • 更新時間
        • 資料更新時間,當資料建立或異動後,此欄位會記錄當時異動的時間
    商品資料表

    說明 欄位名稱 欄位屬性
    商品編號 id integer
    商品狀態 status varchar(1)
    商品名稱 name varchar(80)
    商品英文名稱 name_en varchar(80)
    商品介紹 introduction text
    商品英文介紹 introduction_en text
    商品照片 photo varchar(50)
    商品價格 price integer
    商品剩餘數量 remain_count integer
    建立時間 created_at datetime
    更新時間 updated_at datetime



      • 商品編號
        • 欄位為主鍵(Primary Key)
        • auto increment自動增加編號
      • 商品狀態
        • 用於標記商品狀態,已上架的商品才能被消費者看到
          • C(Create):建立中
          • S(Sell):可販售
      • 商品名稱
        • 商品名稱
      • 商品英文名稱
        • 用於顯示商品名稱,當語系為英文時,則顯示英文名稱
      • 商品介紹
        • 商品介紹
      • 商品英文介紹
        • 用於顯示商品相關介紹,當語系為英文時,則顯示英文介紹
      • 商品照片
        • 紀錄照片路徑,用於顯示商品照片
      • 商品價格
        • 單一商品購買價格
      • 商品剩餘數量
        • 商品剩餘可購買數量
      • 建立時間
        • 資料建立時的時間,建立後此欄位資料永遠不會變
      • 更新時間
        • 資料更新時間,當資料建立或異動後,此欄位會記錄當時異動的時間
    交易紀錄資料表

    說明 欄位名稱 欄位屬性
    交易編號 id integer
    使用者編號 user_id integer
    商品編號 merchandise_id integer
    當時購買價格 price integer
    購買數量 buy_count integer
    交易總金額 total_price integer
    建立時間 created_at datetime
    更新時間 updated_at datetime



      • 交易編號
        • 欄位為主鍵(Primary Key)
        • auto increment自動增加編號
      • 使用者編號
        • 購買此商品的使用者是誰,會記錄使用者編號
      • 商品編號
        • 使用者購買什麼商品,會記錄商品編號
      • 當時購買價格
        • 商品當時購買價格
      • 購買數量
        • 使用者購買商品數量
      • 交易總金額
        • 使用者在此交易購買總價格(當時購買價格*購買數量)
      • 建立時間
        • 資料建立時的時間,建立後此欄位資料永遠不會變
      • 更新時間
        • 資料更新時間,當資料建立或異動後,此欄位會記錄當時異動的時間
     
  4. yoching

    yoching 站務人員
    管理成員

    註冊:
    2016-10-01
    文章:
    40
    讚:
    3
    [Day 03] 事前規劃 - 網址設計規劃

    網址規範
    在網址的設計規劃中,網址的階層是有主從關係,越前面的網址,屬於越上層的資訊,如果要對這個資源做額外動作處理的話,在最後面就會加上動作名稱。
    /資源/{資源編號}/{動作?}
    如果是對資源要做最基本的檢視、新增、刪除及修改動作的話,我們會使用Http方法(HTTP Method)去做相對應的資料處理。

    動作說明 方法
    檢視 GET
    新增 POST
    刪除 DELETE
    修改 PUT
    網址主從關係設計
    根據這樣的情境跟網址設計規範,我們可以將我們電子商務網站的網址設計成下列這個樣子

    說明 網址規範
    首頁 /
    使用者註冊 /user/auth/sign-up
    使用者登入 /user/auth/sign-in
    使用者登出 /user/auth/sign-out
    商品清單檢視 /merchandise
    商品管理清單檢視 /merchandise/manage
    商品上架 /merchandise/create
    商品單品檢視 /merchandise/{merchandise_id}
    商品單品編輯 /merchandise/{merchandise_id}/edit
    購買商品 /merchandise/{merchandise_id}/buy
    交易紀錄 /transaction
    這些網站的階層規劃因為主從性的關係,所以可以閱讀及理解他們要表達的涵義,

    • 像是使用者註冊的網址規劃部分
      /user/auth/sign-up
      在閱讀上我們可以理解成使用者(user)的身分驗證(auth)資料,要做註冊(sign-up)的動作
    • 而在使用者登入的網址規劃部分
      /user/auth/sign-in
      在閱讀上我們可以理解成使用者(user)的身分驗證(auth)資料,要做登入(sign-in)的動作
    • 當然使用者在正式的電子商務網站中,還會有使用者個人資料編輯的網址,網址可能會像是
      /user/profile/edit
      在閱讀上我們可以理解成使用者(user)的個人資料(profile)資料,要做編輯(edit)的動作
    • 而在購買商品的網址規劃的部份
      /merchandise/{merchandise_id}/buy
      我們可以看到在最後面多一個額外的動作名稱buy(購買),這是因為除了對商品座最基本的檢視、新增、刪除及修改,我們還要對這個商品做額外的購物的商業邏輯動作,而這個動作我們就需要額外寫出來,所以在閱讀上可以理解成商品(merchandise)的哪個商品編號(merchandise_id),我們要做購買(buy)的動作
    在正式的電子商務網站中,會將所有商品加入購物車,然後在購物車那邊進行消費的動作,所以網址的規畫可能會像是

    說明 網址規範
    商品加入購物車 /merchandise/{merchandise_id}/add-to-shopping-cart
    購物車商品清單 /shopping-cart
    購物車商品清單結帳 /shopping-cart/buy
    用這樣階層的主從關係,我們可以很容易地理解每個網址、每個資源的關係及用途是什麼。

    網址主從關係設計與HTTP方法

    在將所有的資源及動作規劃好後,我們可以加入HTTP方法去對資源做最基本的檢視、新增、刪除及修改動作處理,加入後的網址及方法對應會像這樣

    說明 網址規範 方法
    首頁 / GET
    使用者註冊頁面 /user/auth/sign-up GET
    使用者資料新增 /user/auth/sign-up POST
    使用者登入頁面 /user/auth/sign-in GET
    使用者登入處理 /user/auth/sign-in POST
    使用者登出 /user/auth/sign-out GET
    商品清單檢視 /merchandise GET
    商品管理清單檢視 /merchandise/manage GET
    商品資料新增 /merchandise/create GET
    商品單品檢視 /merchandise/{merchandise_id} GET
    商品單品編輯頁面檢視 /merchandise/{merchandise_id}/edit GET
    商品單品資料修改 /merchandise/{merchandise_id} PUT
    購買商品 /merchandise/{merchandise_id}/buy POST
    交易記錄 /transaction GET
    在加入HTTP方法後原本的 商品資源 網址 /merchandise 就會有兩個不一樣的動作,分別是檢視(GET)及新增(POST)的動作。

    說明 網址規範 方法
    商品清單檢視 /merchandise GET
    商品上架資料新增 /merchandise POST
    商品單品檢視 /merchandise/{merchandise_id} GET
    商品單品資料修改 /merchandise/{merchandise_id} PUT
    商品單品資料刪除 /merchandise/{merchandise_id} DELETE
    而在原本商品單品的網址 /merchandise/{merchandise_id} 也會有2個不一樣的動作,分別是檢視(GET)及新增(POST)的動作,而正式的電子商務網站會有需要對商品做刪除的需求時,我們就會加入刪除(DELETE)的動作。


     

分享此頁面

正在載入...