เรื่อง MVC ต่อจากเมื่อวานหน่อย .... เห็นมีคนแชร์กันเยอะ
ลองมองว่า MVC ไม่ใช่ Design Pattern และไม่ใช่แค่ Architecture Pattern สำหรับอะไรอย่างใดอย่างหนึ่งโดยเฉพาะ
MVC มันเป็น "ปรัชญา" สำหรับ Separation of Concern
1. M = ตัวตนของสิ่งที่ "มัน" เป็น
2. V = ภาพที่ "มัน" ถูกมองเห็น ถูกใช้งาน
3. C = ตัวกลางระหว่าง M, V
สิ่งที่เรามองเห็น อาจจะไม่ใช่สิ่งที่มันเป็น .... สิ่งที่มันเป็นอาจจะไม่ใช่สิ่งที่เราใช้และต้องการ .... เราต้องแยกปัจจัยพวกนี้ให้ได้ ไม่ใช่ไปยึดติด
ถ้า M ยึดติดกับ V ก็ไม่ดี ... ถ้า V ยึดติดกับ M ก็ไม่ดี .... ก็ต้องแยกสองอย่างนี้ออกจาก ...
ทางเดียวที่ทำได้ ก็ต้องมี C มาเป็นตัวกลาง .....
อย่าไปยึดติดอะไรกับมันมากนัก ปรัชญาของมันทำให้เรางอก "MVC ภายใน MVC" ได้อีกเยอะแยะมากมาย
เอาหลักการนี้ไปจับกับอะไรก็ได้ทั้งนั้นแหละ ..... ลองดูนะ .... เช่น
1. ถ้าเราถือว่าข้อมูลใน DB เป็น "ตัวตน" และ Entity/Model ใน Application เป็นสิ่งที่มันถูกมองเห็น ถูกนำไปใช้ เราก็ใช้ SQL Query (และอาจจะ + ORM) เป็นตัวกลาง ..... เราก็จะไม่ยัด SQL ไปใน Entity/Model เพราะมันคือ View ของ Data ใน DB ... เราก็เขียน Persist layer มาจัดการ
2. ถ้าเราถือว่า Object ใน Application ของเราเป็น "ตัวตน" และ JSON ที่ถูกพ่นออกไปเป็นสิ่งที่มันถูกนำไปใช้ เราก็สร้าง JSON Presenter สำหรับมันในบริบทต่างๆ เป็น View และใช้ตัวกลางอะไรสักอย่างมา Map ไป
อะไรแบบนี้เป็นต้น
MVC มันห่วย ถ้าเรามองมันเป็นแค่ Fixed Architectural Implementation ในบริบทใดบริบทหนึ่ง และมันห่วยเสมอเมื่อบริบทมันไม่ใช่บริบทเดียวกับที่มันถูก Implement มา .....
แต่หลาย Architecture ที่เกิดขึ้น ที่คนบอกว่ามันเจ๋งมากมาย ต้องทำแบบนี้ถึงจะถูก ฯลฯ ก็คือการเอาความคิดแบบ MVC นี่แหละ ไป Refactor แต่ละ Layer ของ MVC .....
ที่เมื่อวานผมเขียน MVC ของ Enterprise มันอยู่ใน Presentation ของ 3-Tier แต่ MVC หลายตัวมันคือ 3-Tier ตรงๆ เลย .... มันก็อีแบบนี้แหละ .... พอ Presentation ของคุณมันใหญ่ มันก็ถูก Refactor ด้วยความคิดแบบ MVC .... แล้วเราก็เรียกมันว่า "MVC Architecture " .... จนกลายเป็นว่า MVC ของเรามันไม่เท่ากัน
ทั้งๆ ที่จริงๆ แล้วมันเป็นหลักการ เป็นปรัชญา .... และเป็น Recursive Pattern .... คือมันสามารถ apply ตัวมันเองลงไปใน layer ไหนก็ได้ของตัวเอง .... เพราะแต่ละ layer ของมัน เมื่อมันเริ่มโตขึ้น มันก็จะ self-similar แบบเดียวกับตัวมันเองน่ะแหละ .... นี่คือ Recursive pattern ชัดๆ .....
หรือถ้าจะเอาปรัชญากว่านั้น ก็ถ้าเราถือว่า "สิ่งที่อยู่ในโลกจริงๆ หรือสิ่งที่ User พูดถึง เป็นตัวตนจริงๆ" และ "ข้อมูลใน DB เป็นสิ่งที่มันถูกมองเห็นหรือถูกนำไปใช้ในระบบเรา" .... เราก็จะมี "คนออกแบบระบบหรือคนออกแบบข้อมูล" (เช่นเราน่ะแหละ) หรือ "คนกรอกข้อมูล" เป็น Controller .....
อีกครั้ง:
สิ่งที่เรามองเห็น อาจจะไม่ใช่สิ่งที่มันเป็น .... สิ่งที่มันเป็นอาจจะไม่ใช่สิ่งที่เราใช้และต้องการ .... เราต้องแยกปัจจัยพวกนี้ให้ได้ ไม่ใช่ไปยึดติด
ถ้า M ยึดติดกับ V ก็ไม่ดี ... ถ้า V ยึดติดกับ M ก็ไม่ดี .... ก็ต้องแยกสองอย่างนี้ออกจาก ...
อย่าไปยึดติดอะไรกับมันนักเลย ลองมองให้ลึกกว่าเปลือกที่แต่ละ Framework หรือแต่ละ Implementation บ้างก็ดี