- อ่านข้อมูล (Read)
- เขียนข้อมูล ( Create)
- แก้ไขข้อมูล (Update)
- ลบข้อมูล ( Delete)
หรือที่โปรแกรมเมอร์ชอบเรียกรวม ๆ กันว่า ( CRUD ) นั่นเอง สำหรับ package ที่สร้างขึ้นมามีวัตถุประสงค์ดังนี้
- ลดการทำงานของ Programmer
- สร้างไฟล์ที่สามารถใช้งานซ้ำได้
- สร้างไฟล์ส่วนที่มีความจำเป็นให้อัตโนมัติ
- เชื่อมโยงไฟล์เข้าด้วยกันแบบอัตโนมัติ
- เพื่อผลิตงานให้ได้ไวที่สุด
ลดการทำงานของ Programmer
ผมพบว่าการสร้าง API หนึ่งเส้นจะต้องมีไฟล์ที่เกี่ยวข้องแบบน้อยสุด 4 ไฟล์ คือ
- route
- controller
- model
- migration (กรณีที่ยังไม่ได้ทำ migration เอาไว้)
จะเห็นว่านี่เป็น API patten ที่แบบทั่วไปซึ่งมันก็สะท้อนว่าถ้าหากเราจะพัฒนาไปใช้ patten อื่น ๆมันต้องมีไฟล์ที่เข้ามาเกี่ยวข้องเยอะกว่านี้แน่นอนเพื่อให้มันทำงานออกมาได้ดีและลดความซับซ้อนของ code ให้มากที่สุด ตัวอย่าง patten ที่ผมใช้คือ Repository patten จะมีไฟล์ที่เข้ามาเกี่ยวข้องดังนี้
- route
- middleware
- request
- controller
- repository
- model
- migration (กรณีที่ยังไม่ได้ทำ migration เอาไว้)
ภาพรวมของ Repository patten มันจะทำงานตามลำดับที่ผมเรียงไว้ด้านบน อธิบายคร่าวการทำงานของมันจะเกิดขึ้นเมื่อ Client create http request เข้ามาผ่าน route เช่น
- url : {base_url}/api/v1/contents
- method : get
- authorization : JWT [การทำ authentication รูปแบบหนึ่ง]
จากนั้นก่อนที่จะส่งข้อมูลไปทำงานจะถูก middleware กรองก่อนชั้นแรก เช่น api ที่เรียกเข้ามาผ่านการ authorization หรือเปล่า หลังจากนั้นจะถูกส่งต่อไปที่ requst ตัวอย่างไฟล์ request มีดังนี้
- request จะทำงานหน้า validate ข้อมูลก่อนที่จะถูกส่งไปประมวลผลที่ controller เรียกอีกอย่างคือ clean data นั้นเอง ส่วนนี้ช่วยให้ข้อมูลที่เข้าไปทำงานที่ repository ทำให้เรามั่นใจได้ว่าข้อมูลมันจะต้องตรงตามที่เราต้องการแน่ ๆ ถ้าไม่ใช่ก็ให้คืนค่ากลับไปทันทีไม่ต้องไปทำงานถึง Repository ส่วนที่เป็น business logic แล้วอีกอย่างก็ไม่ต้องไปเช็คเงื่อนไขข้างในเกี่ยวกับ ข้อมูลอีกด้วยช่วยให้ลดบรรทัดของ code ไปเยอะมาก ๆ
หลังจากที่ผ่านการ validate data (clean data) เรียบร้อยแล้วข้อมูลจะถูกส่งต่อไปที่ controller ในส่วนของ controller ของ laravel มันมีความสามารถค่อนข้างหลากหลายเช่นใส่ middleware ตรง controller ก็ได้ แต่สำหรับ package : samark/lumpineevill ผมจะไม่ให้ทำอะไรมาก เพียงให้มันเป็นตัวเชื่อมระหว่าง request -> controller -> repository เพียงเท่านั้นเอง code ที่ออกมาจึงไม่มีเงื่อนไขใด ๆทั้งสิ้น ดังตัวอย่างต่อไปนี้
- จะเห็นว่า code ไม่มีการเช็คเงื่อนไขใด ๆ ทั้งสิ้นผมชอบมันตรงที่ดูแล้วมันสะอาด จริง ๆ มันก็ไม่ได้ถึงกับว่าดี เพราะมีบางกรณีที่ต้องการเช็ค ฉะนั้นถ้า API เส้นไหนที่ต้องการเช็คค่อยมาเพิ่มเองทีหลังแต่โดยรายละเอียดของ code ที่ถูกสร้างขึ้นมาแถบจะไม่ต้องแก้เพราะมันสามารถทำงานได้ทันที
ส่วนต่อมาคือ Repository ไฟล์นี้ก็ถูกสร้างขึ้นมาอัตโนมัติจาก samark/lumpineevill เช่นเดียวกันหน้าที่ของมันคือเชื่อมโยงระหว่าง controll -> repository -> model , business logic(business logic คือ กระบวนการประมวลผลที่ต้องมีการตรวจสอบเงื่อนไขต่าง ๆ ของข้อมูล การจัดการข้อมูลเป็นต้น) ต่าง ๆจะถูกนำมาวางไว้ที่นี้เพื่อลดความซ้ำซ้อนนั่นเอง (ความซ้ำซ้อนคือการเขียน code ชุดเดิม copy ไปไว้ที่อื่น ตอนจะแก้ต้องแก้หลาย ๆ ที่) ตัวอย่างไฟล์ repository ที่ถูกสร้างขึ้นมาด้วย samark/lumpineevill
- ส่วนของ repository พื้นฐานที่ถูกสร้างขึ้นมาจะเห็นว่ามีบรรทัดค่อนข้างน้อย แต่ความเป็นจริงแล้วความซ้ำซ้อนทั้งหมดผมนำไปไว้ที่ BaseRepository ทำให้ class ที่ extends (แตก) ออกมาจาก class BaseRepository มันไม่จำเป็นต้องเขียนยาวแต่มีคุณสมบัติเหมือนกับแม่มันเดะคุณสมบัตินี้เรียกว่า การสืบทอด(อำนาจ) ในทฤษฏีของ OOP (object oriented programming) นั่นเอง
เอาละต่อมาจะมาลองใช้งาน samark/lumpinee กับ laravel 5.* กันสิ่งที่ต้องเตรียมมีดังนี้ ปล.ขั้นตอนการติดตั้ง laravel framwork ผมไม่ขอลงรายเอียดสามารถกลับไปอ่านได้ในบทความเก่า เกี่ยวกับการติดตั้ง laravel ได้ครับ
- laravel 5.* [composer create-project laravel/laravel {project-name}]
หลังจากที่เรามี laravel framwork เรียบร้อยแล้วสิ่งต่อมาคือติดตั้ง samark/lumpineevill ด้วย composer ดังนี้
- composer require samark/lumpineevill
หลังจากที่ติดตั้ง samark/lumpineevill เสร็ดแล้ว ขั้นตอนต่อให้เพิ่มบรรทัดที่ config/app.php ในส่วนของ array providers ดังนี้
- Lumpineevill\ServiceProvider\LumpineevillServiceProvider::class,
ถ้าไม่มีอะไรผิดพลาดลองพิมพ์คำสั่ง [ php artisan ] มันจะมีคำสั่งหนึ่งเพิ่มเข้ามาคือ samark:genfile
- samark
- samark:genfile Generate file
- What is your namespace ?: >
- ให้ใส่ชื่อ module ที่คุณต้องการสร้างได้เลย คำแนะนำเพิ่มเติมให้พิมพ์เป็น camel case จะเป็นวิธีที่ดีที่สุด
- สำหรับตัวอย่างนี้ผมจะใส่ blog เข้าไป
สิ่งแรกที่จะต้องเข้าไปแก้คือ migration ไฟล์ คือคำสั่งที่พิมพ์ไปเมื่อกี้มันสร้าง migration ไฟล์ขึ้นมาให้ด้วย ไปที่ database/migration/create_table_blog_{datetime}.php ตัวอย่างไฟล์
- Migrated: 2018_05_31_012157_create_table_blog
หลังจากนั้นลองย้อนไปที่ routes/api.php จะพบว่า samark/lumpineevill ได้เพิ่ม route ให้แล้วเรียบร้อยดังนี้
อีกจุดหนึ่งที่จะลืมแก้ไม่ได้เด็ด ! คือ request เพื่อกรองข้อมูลก่อนส่งไปยัง controller นั่นเอง ซึ่งตัว blog เองผมต้องการข้อมูลอยู่สองอย่างเดียวกันคือ
- topic
- detail
ดังนั้นตัว request ในการสร้างข้อมูลจึงจะต้อง required ข้อมูลเหล่านี้ดังตัวอย่างต่อไปนี้
ต่อมาลองทดสอบเรียกข้อมูลที่ถูกสร้างไปเมื่อสักครู่ ด้วย postman ดังภาพ
สำหรับ samark/lumpineevill ตัวนี้มีความสามารถในการ search column เรียกได้ว่าครบทุก column ที่มีอยู่ใน table โดยที่ไม่ต้องแก้ API อะไรเลยมันสะดวกมาก ๆ
สรุป ข้อดีข้อเสียของ samark/lumpineevill
# ข้อดี
สำหรับ samark/lumpineevill ตัวนี้มีความสามารถในการ search column เรียกได้ว่าครบทุก column ที่มีอยู่ใน table โดยที่ไม่ต้องแก้ API อะไรเลยมันสะดวกมาก ๆ
สรุป ข้อดีข้อเสียของ samark/lumpineevill
# ข้อดี
- เป็นเครื่องมือที่สร้าง API ได้ไวที่สุดบน Repository patten
- ใช้งานง่าย ติดตั้งง่ายด้วย composer
- เหมาะสำหรับผู้เริ่มต้นเขียน API ใหม่และอยากมาลองให้ Repository patten
- ไฟล์งานแยกเป็นส่วน ๆ ทำให้หาง่าย
# ข้อเสีย
- มีไฟล์บางไฟล์ที่ไม่ต้องการถูกสร้างขึ้นมาด้วย
- API response ไม่ใช่ standard
- มีไฟล์ค่อนข้างเยอะ
สุดท้ายอยากให้ลองนำไปใช้กันดูครับ ดีไม่หรือไม่ดียังไงลอง feed back กลับมาได้ที่ github ของ repo ได้เลย
ปล.งานชิ้นนี้ทำไว้เพื่อสร้างแรงบันดาลใจในการสร้างงานชิ้นถัด ๆ ไป
ปล.งานชิ้นนี้ทำไว้เพื่อสร้างแรงบันดาลใจในการสร้างงานชิ้นถัด ๆ ไป
ด้วยความที่ผมเบื่อกับการ copy ด้วยมือผมจึงสร้างเครื่องมือนี้ขึ้นมาไม่ต้องกังวลว่าจะทำไฟล์ครบหรือไม่อีกต่อไป.
ขอบคุณที่อ่านจนจบนะครับ ...
0 ความคิดเห็น:
แสดงความคิดเห็น