Table of contents
Intro
สวัสดีครับ บทความนี้จะเป็นการรีวิว Laravel Framework โดยจะพาเข้าสู่จักรวาลของ Laravel ซึ่งเป็น Web Framework แบบ MVC ของภาษา PHP โดยได้รับความนิยมอย่างมาก (สูงสุดของ Framework ภาษา PHP) โดยบทความนี้ก็จะมาเล่าถึงข้อดี และ ข้อเสีย ฉบับผู้ใช้งานจริงจัง (หมายถึงใช้งานระดับ Production มาหลาย Projects แล้ว) ที่ไม่ใช่แค่ลองเล่น หรือทำแค่ CRUD 😅 โดยก็จะเป็นการรีวิวแบบตรงไป ตรงมา ด ีก็ว่าดี แย่ก็ว่าแย่นะครับ 😊
หากคำพูดส่วนใดไม่ถูกต้อง หรือใครมีข้อเสนอแนะอยากเพิ่มเติม สามารถเขียนลงที่ช่องแสดงความคิดเห็นได้เลยนะครับ ผมเองยินดีรับฟังทุกความคิดเห็นเพื่อเอามาปรับปรุงเนื้อหาในบทความนี้ครับ 🙏
เกี่ยวกับ Laravel เบื้องต้น
Laravel คือ PHP Framework* แบบโอเพ่นซอร์สฟรี ที่ถูกออกแบบมาเพื่อพัฒนาเว็บแอปพลิเคชั่นด้วยภาษา PHP (server-side) โดยใช้รูปแบบสถาปัตยกรรม Model-View-Controller (MVC) (บน github มียอดดาว 76.2k เมื่อ 02/2024)
Framework* คือกรอบหรือข้อตกลงสำหรับการใช้งาน (Conventional) ที่กำหนดโดยผู้พัฒนา Framework ซึ่งได้กำหนดกฎเกณฑ์สำหรับการพัฒนาไว้แล้ว ดังนั้น Framework จึงเหมาะสำหรับการพัฒนาระบบเป็นทีม ที่ต้องการความยืดหยุ่น กรอบแบบแผนที่ชัดเจน เพื่อใช้สื่อสารกันในทีมได้ง่าย อีกทั้งยังบำรุงรักษา Code ได้ง่ายเป็นระบบ
Reviews
บทความนี้จะสรุปและรีวิวจากประสบการณ์ที่ได้ใช้งานอย่างจริงจังมาเกือบ 2 ปี โดยอ้างอิง Laravel 8.x เป็นหลักนะครับ (รุ่นล่าสุดขณะที่เขียนบทความ) และก่อนอื่นผมต้องขอนิยาม Laravel ไว้ว่า "Framework ที่ดี ที่ต้อง แลกมาด้วยประสิทธิภาพ
😅" โดยส่วนตัวได้ใช้งานมาแล้วก็มีความคิดเห็นว่าเป็น Framework ที่ดีมากตัวนึง ดังนั้นแนวการรีวิวของบทความนี้ก็จะพูดถึงรูปแบบ Web Framework ที่ดีที่ควรจะเป็นนะครับ โดย Web Framework ที่ดีที่ควรจะเป็นซึ่งตรงนี้ไม่ได้อ้างอิงจากที่ไหน เพราะผมได้สรุปตามประสบการณ์ของผมโดยตรงเลย 😊
1. การติดตั้ง (Development)
(★★★★ 4/5)
การติดตั้งสำหรับสภาพแวดล้อม Development นั้นเรียกได้ว่าติดตั้งง่ายสามารถติดตั้งผ่าน Composer (อารมณ์เหมือน NPM ของ JS) Docs ของ Laravel ก็มีรายละเอียดการติดตั้งบนหลาย OS ที่เขียนไว้ดี (รายละเอียด) อยากได้ Packages อะไรเพิ่มก็ลงผ่าน Composer มี Auto-discovery ไม่ต้องไป Configs เปิด ใช้งานให้ยุ่งยาก
ข้อดี
- Docs มีรายละเอียดการติดตั้งบนหลาย OS
- มี Sail Services (รายละเอียด) ที่นิยามไว้ว่า "
Laravel Sail is a light-weight command-line interface for interacting with Laravel's default Docker development environment
" เบื้องหลังการทำงานคือ Docker ทำให้การ Setup Environment สำหรับการ Development นั้นง่ายขึ้นโดยไม่ต้องสนใจเรื่อง OS Platforms - มีคำสั่ง
php artisan serve
ที่รันแล้วได้ URLhttp://localhost:8000
สำหรับ Development Mode สำหรับใครที่ต้องการทดลองอะไรง่าย ๆ และรวดเร็ว
ข้อเสีย
- ก็ไม่เชิงว่าเป็นข้อเสียอะไร เนื่องจาก Docs มีรายละเอียดการติดตั้งไว้หลายวิธี แต่ถ้า Docs แนะนำว่าวิธีไหนที่เป็น Best Practices สำหรับมือใหม่คงดีไม่น้อย เพราะการใช้งานจริง ๆ เราอาจจะต้อง Dev หลายโปรเจคพร้อม ๆ กันดังนั้นต้องวางระบบ Environments อย่างไร
- ที่จริงข้อนี้ก็เหมือนข้อแนะนำมากกว่า เพราะ Docs เขาไม่ได้แนะนำไว้ คือการแนะนำ IDE แนะนำ Plugin ของ IDE หรือการติดตั้งเครื่องมือสำหรับ Debugger โดยมีประโยชน์มาก ๆ เพราะจะช่วยเรื่องความรวดเร็วในการพัฒนาแถมยังช่วยลดข้อผิดพลาดได้ด้วย
2. ระบบ Environment Configuration
(★★★★★ 5/5)
ระบบ Environment Configuration เรียกสั้น ๆ ว่า ENV โดยเป็นการกำหนดค่า Configs ต่าง ๆ ที่ไฟล์ .env
(เป็นมาตรฐานส่วนใหญ่อยู่แล้ว) ถ้าคนที่เคยใช้มาก่อนก็จะคุ้นแน่นอน ประโยชน์หลักของ .env
ก็คือการกำหนด Configs ต่าง ๆ ไม่ว่าจะเป็น Keys ต่าง ๆ ที่เราไม่อยากเก็บลง Code (ที่จริงก็ไม่ควรเก็บค่า Keys ต่าง ๆ ลงบน Code) โดยสิ่งที่ผมชอบมากกับ .env
ของ Laravel คือมันใช้ร่วมกับ Laravel-Mix ที่เป็น Frontend ได้ด้วยถือว่าดีเลยทีเดียว 👍
ไม่ควรเก็บค่า Secret Keys ต่าง ๆ ไว้บน Code โดยตรงแต่ให้ใช้ ENV แทนเพราะจะมีปัญหาเรื่องความปลอดภัย โดยถ้าเก็บ Code ไว้ที่ Git ค่า Keys เหล่านั้นก็ตามไปด้วย แถมถึงแม้จะลบ Keys ใน Code ส่วนนั้นออกแต่ History ที่อยู่บน Git ก็ไม่หายนะครับ ถือเป็นบาปที่หนามาก ...ล้างไม่ได้ง่าย ๆ 🤣
ข้อดี
- มีการกำหนดค่า Configs ต่าง ๆ ที่ไฟล์
.env
(เป็นมาตรฐานส่วนใหญ่) - ใช้
.env
ของ Laravel ผสมร่วมกับ Laravel Mix ที่เป็น Frontend ได้ด้วย - มีการมาตรฐานการเก็บ Secret keys และการเรียกใช้งานที่ดี เช่น เมื่อเราเก็บค่า Secret Keys ไว้ที่
.env
แต่ระบบจะไม่แนะนำให้ด ึงค่าจาก.env
โดยตรงแต่จะมีการทำ Constant Configs ไฟล์สำหรับเรียกใช้งานต่ออีกทีนึง - มีระบบ Configuration Caching
.env
ประโยชน์หลัก ๆ คือช่วยเรื่องความเร็วในการโหลด Core Framework (ตรงนี้ไม่ได้เป็น Default นะครับ ถ้าอยากใช้งานต้องสั่งphp artisan config:cache
และเมื่อมีการเปลี่ยนแปลงค่าใน.env
ก็ต้องสั่งรันคำสั่งนี้ใหม่ทุกครั้ง ทั้งนี้การใช้คำสั่งนี้จะทำให้เรียกใช้งาน.env
โดยตรงไม่ได้ ต้องเรียกผ่าน Configs ไฟล์เท่านั้น ตรงนี้ต้องทำความเข้าใจดี ๆ ก่อนใช้งานครับ) - สามารถ เปิด - ปิด Debug Mode ผ่าน
.env
จากAPP_DEBUG=true
หรือAPP_DEBUG=false
- สามารถ เปิด - ปิด Maintenance Mode ด้วยคำสั่ง php artisan down หรือ php artisan up (มีประโยชน์เมื่อหากเราต้องการปิดปรับปรุงระบบจากนั้นระบบก็จะแสดงหน้า Maintenance Mode) ที่จริงมีรายละเอียดที่น่าสนใจ เช่น การสั่ง Redirect หน้า หรือ การเลือกหน้าสำหรับ Render views (รายละเอียด)
ข้อเสีย
- ยังนึกไม่ออก
3. ระบบ Directory Structure
(★★★ 3/5)
Laravel ประกอบไปด้วย Directory Structure เยอะมาก คนที่เพิ่งมาเรียนรู้แรก ๆ ก็คงจะ งง อยู่ว่าแต่ละตัวคืออะไร ทำไมแยกย่อยเยอะเกิน พอใช้ไปสักพักพอเข้าใจ และก็คงจะเข้าใจเจตนาผู้พัฒนาว่าคงต้องการกำหนด Structure มาแบบนี้เพราะต้องการให้นักพัฒนาที่ใช้ Directory Structure ที่เป็นมาตรฐานเดียวกัน
ข้อดี
- กำหนด Directory Structure มาให้ (แต่ก็เปลี่ยนได้ถ้าต้องการ)
- มี Directory เยอะก็จริง (มาพร้อมกับการติดตั้ง) แต่ก็เป็น Directory ที่จำเป็นสำหรับการใช้งาน (ไม่ได้มีไว้แบบเปล่าประโยชน์)
- แยก Directory เยอะเป็นสัดส่วน อาจจะไม่ค่อยมีประโยชน์ถ้า Dev คนเดียว แต่จะมีประโย ชน์มากถ้า Dev เป็นทีมเนื่องจากมีระเบียบเรียบร้อย
ข้อเสีย
- Framework ไม่ได้รองรับระบบ Modular Applications (Modules) หมายถึงการแยกส่วนพัฒนาแบบ Modules (ก่อนอื่นคุณต้องทำความเข้าใจเรื่อง Modular Software Architecture ก่อน) ตรงนี้เป็นข้อเสียอย่างมาก ที่จริงสามารถ Customs ได้ (ทั้งทำเองบ้าง ทั้งหา Packages เกี่ยวกับการทำ Modules ...ผมเคยพยายามมาแล้ว) แต่สรุปแล้วก็ไม่ดีไปซะทีเดียว เนื่องจากมันไม่จะไม่ถูกตามมาตรฐานของ Laravel (บาง Packages ที่ช่วยทำ Module ก็สร้างระบบ Directory เกินความจำเป็น บางทีอาจจะทำให้ระบบทำงานช้าด้วยซ้ำ) จะมีปัญหาตามมาหลายอย่าง เช่น การ Upgrade Versioning ระบบก็จะยุ่งยากขึ้น เนื่องจากเรา Customs Project ไว้ไม่เป็นไปตามมาตรฐานของ Laravel
- เนื่องไม่มีความเป็น Modular Applications ทำให้การพัฒนา Project ร่วมกับทีม Dev นั้นทุกคนต้องมีไฟล์ระบบ Project ที่เหมือน ๆ กันยิ่ง Project ขนาดใหญ่ก็ยิ่ง เยอะ ไม่สามารถแยกส่วนการพัฒนา Module ที่ชัดเจนได้ทำให้อาจจะมีปัญหาแก้ไขไฟล์เดียวกัน (Conflicted files) ไม่สามารถ เปิด - ปิด เฉพาะ Module ที่ต้องพัฒนา หรือใช้งานได้
- แนวทางการแก้ปัญหา Modular Applications ก็พอมีอยู่บ้างก็คือการทำ Private packages ด้วย Composer อ่านดูวิธีการแล้ว... ดูแล้วมันก็ไม่ได้สะดวกไปซะทีเดียวใช่ไหมครับ 😅
- ก็ไม่เชิงว่าเป็นข้อเสียของ Framework โดยตรง เพราะเนื่องจาก Laravel เป็น MVC Framework ดังนั้นการวางโครงสร้าง Files สำหรับ Models-Views-Controllers มีความสำคัญมาก ซึ่งตรงนี้เราสามารถวางโครงสร้างได้อย่างอิสระ แต่ถ้าวางโครงสร้างไว้ไม่ดีตั้งแต่ทีแรก เมื่อ Project มีขนาดใหญ่ขึ้นระบบจะไม่มีความมีระเบียบเรียบร้อย ดังนั้นตรงนี้ ควรหาอ่านพวก Best Practices เช่น การตั้งชื่อไฟล์ การตั้งชื่อ Directory ต่าง ๆ
4. ระบบ Routing
(★★★★★ 5/5)
ระบบ Routing ของ Framework แบ่งระบบ Routing ออกเป็น Web และ API ชัดเจน โดยระบบ Routes ของ Laravel ได้แยกออกมาเป็นไฟล์ (routes/web.php, routes/api.php) ข้อนี้ผมให้ 5 ดาวไปเลย ส่วนตัวชอบมาก เพราะระบบออกแบบไว้ดี ที่จริงความสามารถของ Routing มีเยอะมาก ๆ แต่ขอยกอันที่ผมชอบมาพูดให้ฟังนะครับ
ข้อดี
-
ก่อนอื่นเราต้องเข้าใจก่อนว่า ระบบ Routing ที่แยกออกมาเป็นไฟล์ จะแตกต่างกับ ระบบ Routing ที่ผูกติดไว้กับ Method ของ Controllers (บาง Framework) นะครับ ซึ่งระบบ Routing แบบแยกไฟล์จะมีความอิสระหลายอย่างที่มีความสามารถเหนือกว่าโดยจะอธิบายในข้อต่อ ๆ ไป
-
กำหนด Routing ได้อิสระมาก ๆ แม้กระทั้งการทำ Routing มากกว่า 2 URLs ไปที่ Method เดียวของ Controller ก็สามารถทำได้
-
ทำ Routing ให้แสดงผลบางอย่างโดยแบบไม่ต้องใช้ Controller ก็ทำได้
-
ทำ Routing โดยแบบไ ม่ต้องใช้ Controller แต่สั่งให้ Render View ที่ต้องการก็ทำได้
-
ทำ Friendly URL ง่าย
-
ทำ Route Groups ได้ เช่น admin/users/1 หรือ admin/users/2 โดยที่ผมชอบมากก็คือ ภายใน Group เราสามารถใส่ Middleware เพื่อทำ Permissions ก่อนจะเข้าถึง Routes นั้น ๆ ได้ด้วย ตัวอย่าง
route/web.phpRoute::group(['prefix' => 'admin', 'middleware' => 'auth'], function() {
Route::get('/users', function () {
// Matches The "/admin/users" URL
});
});infoGroup Routing นั้นมีประโยชน์ในการทำ Group Permissions หรือ Group Resources ช่วยให้การพัฒนา และ Maintenance ระบบง่าย
-
ระบบ Routing มี Methods ดังนี้
สำหรับ HTTP request methodsRoute::get($uri, $callback);
Route::post($uri, $callback);
Route::put($uri, $callback);
Route::patch($uri, $callback);
Route::delete($uri, $callback);
Route::options($uri, $callback); -
สามารถทำเงื่อนไขการ Matching และ Any Methods ได้ ตัวอย่าง
ตัวอย่าง Matching และ Any MethodsRoute::match(['get', 'post'], '/', function () {
//
});
Route::any('/', function () {
//
}); -
ทำ Rate Limiting ได้ หมายถึงการกำหนดจำนวนจำกัดสำหรับการเข้าถึง Route ต่อนาทีได้
-
มี Method Spoofing สำหรับ CSRF (การโจมตีแบบ Cross-site Request Forgery)
-
มี CORS ให้ตั้งค่าสำหรับการงานแบบ API เมื่อมีความจำเป็นที่ต้อง Share resource ข้าม Origin
ข้อเสีย
-
เนื่องจากระบบ Routing ของ Laravel นั้นมีความอิสระในการวาง Routes และถ้าวางโครงสร้างไว้ไม่ดีตั้งแต่แรกจะมีปัญหาเรื่องความซ้ำซ้อนเมื่อ Projects มีขนาดใหญ่ขึ้น
-
มือใหม่ควรศึกษา Best Practices การวาง Route Resource ไม่งั้นถ้าวางมั่วหรือตามใจ Routes จะมีความเข้าใจยากเมื่อทำงานเป็นทีม
-
ไม่ควรเขียนทุก Routes ไว้ในไฟล์เดียว (web.php หรือ api.php) กรณี Project มีหลายระบบก็ควรแยกไฟล์ Routes ระบบต่าง ๆ ออกจากไฟล์หลักก่อน จากนั้นค่อยนำมารวมกัน ตัวอย่าง
route/wep.phpRoute::group(['middleware' => 'auth'], function() {
// Home
Route::group(['prefix' => 'home'], __DIR__.'/app/home.php');
// System manage
Route::group(['prefix' => 'system/manage', 'middleware' => 'is.admin'], __DIR__.'/app/systems.php');
// User profile
Route::group(['prefix' => 'user', 'middleware' => 'is.owner'], __DIR__.'/app/userProfile.php');
});
5. ระบบ Middleware
(★★★★ 4.5/5)
Laravel นั้นมีระบบ Middleware สำหรับใช้เพื่อตรวจสอบตามเงื่อนไขก่อนที่จะอนุญาตหรือไม่อนุญาตให้ดำเนินการต่อ เมื่อมี Request ไปที่ Route
(บาง Framework เรียก Interceptors) อธิบายง่าย ๆ โดยยกตัวอย่างกระบวนการดังนี้
แบบไม่มี Middleware
Request -> Route -> Controller -> View
แบบมี Middleware
Request -> Route -> Middleware -> Route -> Controller -> View
จะเห็นว่าแบบที่มี Middleware มาคั่นนั้นสามารถทำเงื่อนไขอะไรบางอย่างเพื่อตรวจสอบก่อนจะไปที่ Route เป้าหมายและไปที่ Controller ซึ่งประโยชน์ของ Middleware นั้นสามารถประยุกต์ทำได้หลากหลาย เช่น การทำ Permissions Authentication Authorize ก่อนเข้าถึง Controller
ข้อดี
- แบ่งเป็น Global Middleware หมายความว่า ทุก Route ต้องผ่าน Global Middleware ทุกครั้งที่มี Request
- Middleware Groups สามารถจัดกลุ่มได้โดยสามารถกำหนด Group โดยให้ Group นั้นประกอบด้วย Middleware อะไรบ้าง
- Sorting Middleware เป็นการจัด Priority Orders ของ Middleware ว่าให้ Middleware ไหนทำงานก่อนหลัง
- มี Terminable Middleware คือการกำหนดกระบวนการทำงานบางอย่างที่ต้องการหลังจาก HTTP response ส่งไปที่ Web browser แล้ว
ข้อเสีย
- น่าจะทำงานช้า เนื่องจากต้องผ่านหลาย Middleware ไหนจะ Global Middleware และพวก Middleware rules กว่าจะตรวจสอบผ่านทั้งหมดแล้วไปที่ Controller
- อื่น ๆ ยังนึกไม่ออก
6. ระบบ Controllers
(★★★★ 4.5/5)
ระบบ Controllers ของ Laravel นั้นเป็นส่วนหนึ่งตามหลักสถาปัตยกรรม MVC สำหรับใครที่คุ้นเคย MVC คงเข้าใจหลักการทำงาน แต่สำหรับมือใหม่ผมขออธิบายสั้น ๆ ว่า Controllers นั้นประกอบด้วย Functions/Methods สำหรับควบคุมเป็นส่วนกำหนดเงื่อนไขต่าง ๆ และการทำงานร่วมกับ View และ Model
ข้อดี
- ทุก Methods ที่ประกาศไว้ใน Controllers จะไม่สามารถเข้าถึงจาก Request ได้โดยตรง (เหมือนบาง Framework) ถ้าไม่ได้ผูก Method ของ Controller ไว้กับ Route ก่อน
- มีความ Simple ของ Class โดยไม่มี Methods แปลก ๆ ที่กำหนดโดย Framework จากการ Inheritance ของ Controller หรือ Options แปลก ๆ และที่จริงต้องบอกว่ามีความเป็น Standard เลยละ
- ชื่อของ Methods กำหนดได้อิสระ (ไม่เหมือนบาง Framework ที่ต้องกำหนดตามที่ Framework บังคับไว้ ไม่งั้นจะทำงานไม่ได้)
- Return Array datasets จะได้ JSON ทันที และ ถ้าทำ Relation ของข้อมูลไว้ ก็จะได้ Data Relation ของข้อมูลออกมาด้วย
- กรณีสั่ง Return Array datasets แล้วกำหนด Pagination ไว้ ก็จะได้ข้อมูล Metadata Page ของ Datasets นั้นด้วย
ข้อเสีย
- กำลังนึก
7. ระบบ Models (ORM) และ Database
(★★★★ 4.5/5)
ที่จริงส่วนการเขียนเพื่อติดต่อกับฐานข้อมูลนั้นแบ่งออกเป็น 2 ส่วนคือ
- ส่วนที่เป็น Query Builder นั้นจะประกอบด้วย Methods สำหรับช่วยเขียน Query เป็น Object โดยที่ไม่จำเป็นต้องเขียนเป็นแบบ Raw Query ที่ไม่ได้อ้างอิงกับกับ Database table ตัวใดตัวนึง
- ส่วนที่เป็น Model Eloquent นั้นจะเป็น Class Model ที่จะทำงานเจาะจงกับ Database Table โดยตรงดังนั้นจึงต้องมีการกำหนดชื่อ Database Table ไว้โดยที่ Class นั้น Extends ความสามารถของ Eloquent ทำให้ได้รับความสามารถของ Query Builder พ่วงมาด้วยซึ่งภายใน Class หลัก ๆ จะประกอบไปด้วยชื่อ Table ของฐานข้อมูล และ Fill-able ของ Attribute Fields ที่อนุญาตให้ Insert ข้อมูลได้
ถ้าหากใช้ Class Model Eloquent แทน Query Builder จะเพิ่มความสะดวกที่ไม่ต้องกำหนดชื่อ Table ทุกครั้งเมื่อเรียกใช้งาน และเนื่องจาก Class Model นั้น Extends ความสามารถของ Eloquent ที่มีความสามารถของ Query Builder อยู่ด้วยทำให้สามารถใช้ Query Builder ได้ด้วยเช่นกัน นอกจากนั้นยังมีความสามารถอื่น ๆ ที่จำเป็นต้องใช้เช่น การทำ Relational Models ทั้ง Mutators และ Casting เป็นต้น
ข้อดี
-
รองรับ Database หลากหลายยี่ห้อ (MySQL/MariaDB, SQL Server, PostgresDB เป็นต้น)
-
มีระบบ Database Migrations (เพื่อควบคุม Versioning ของ Database Tables มีประโยชน์อย่างยิ่งเมื่อทำงานเป็นทีม)
-
มีการทำ Factories และ Seeders สำหรับการเตรียมข้อมูล (หากต้องการให้ครั้งแรกระบบสามารถ Install ได้)
-
มี ORM ของตัวเอง (Eloquent ORM) ที่พัฒนาเองทีม Laravel
-
มี Query Builder ที่มี Methods พร้อมใช้ที่ครบครันมาก ๆ ตัวนึงเลย
-
ระบบ Class Models สามารถกำหนด Database Connections แยกกันได้อิสระ หรือแม้กระทั่งต่างยี่ห้อ แถมยังทำ Relationships ร่วมกันได้อีก บาง Framework ไม่สามารถทำได้ขนาดนี้ 👍
-
มี Soft Deleting (เป็น Optional) เพื่อกำหนดไม่ต้องลบข้อมูลจริง ๆ ออกจาก Database แต่จะทำ Timestamp Record นั้นแทนการลบข้อมูล
-
มี Accessors & Mutators ที่ Model Class มีประโยชน์หากต้องการเปลี่ยนแปงข้อมูลก่อนแสดงผล หรือ Re-format ข้อมูลบางอย่างก่อน Save ข้อมูลไปที่ Database
-
ทำ API Resources ได้ โดยที่ API Resources คือ Concept การกำหนด Resources ที่หุ้ม Models ไว้อีกที โดยสามารถกำหนดรูปแบบ Array สำหรับการ Response ทำ Data wrapping และ ทำ Pagination ให้ข้อมูล
-
ข้อมูลประเภท Datetime ถ้า Return ออกเป็น JSON จะได้ Format มาตรฐาน ISO-8601 ทันที
-
ระบบ Relationships ของ Models สนับสนุนการทำความสัมพันธ์เยอะมาก (ตัวช่วย) เช่น
Relationship methodsOne To One
One To Many
Many To Many
Has One Through
Has Many Through
One To One (Polymorphic)
One To Many (Polymorphic)
Many To Many (Polymorphic)
ระบบ Relational ของ Models นั้นมีความสำคัญมาก เนื่องจากกระบวนการตรงนี้ช่วยให้เรียกข้อมูลตามสัมพันธ์ได้ง่าย โดยไม่ต้องเขียน SQL Query ตรง ๆ
- เมื่อใช้ Relationships ของ Laravel เต็มรูปแบบ ทำให้เกิดการเขียนโปรแกรมที่ไม่มีการ JOIN Tables ตรงนี้ไม่ใช่มุกตลกนะครับ 😅 แต่การทำ Relation ใน Laravel นั้นเบื้องหลังการทำงานจะไม่มีการ JOIN Tables ของ Database ตรงนี้ก็มีทั้งข้อดีและข้อเสีย แต่จากผมที่ใช้งานมาผมคิดว่ามันดีมากกว่าจะเป็นข้อเสียครับ กลายเป็นว่าผมไม่ได้ JOIN Tables เหมือนแต่ก่อนเลย จะมีการ JOIN ก็ต่อเมื่ออยากทำจริง ๆ เช่นการทำ Report หรือ เมื่อคิดว่าการ JOIN นั้นให้ประสิทธิภาพดีกว่าสำหรับบางงาน
- รองรับการทำ Eager Loading และ Lazy Eager Loading และมี Methods พิเศษ เช่น Aggregating Related Models สำหรับช่วยทำการคำนวณ
ข้อเสีย
- กำลังนึก