เวลาเจอแฟนทิ้ง ให้บอกตัวเองว่า นี่คือความเป็นอนิจจังที่ทุกชีวิตมีโอกาสพานพบ

ว.วชิรเมธี

MVP Model-View-Presenter
User Rating: / 1
PoorBest 

ใน MVP นั้น Presenter จะบรรจุไปด้วย business logic ที่เกี่ยวข้องกับส่วนติดต่อผู้ใช้สำหรับ View และทุก ๆ การเรียกใช้จาก View จะส่งต่อ (delegate) ไปโดยตรงยัง Presenter โดยนั้นจะ Presenter แยก (decouple) จาก View และคุยกันผ่าน interface ซึ่งจุดนี้จะเป็นการช่วยให้สามารถ mock ตัว View ได้ในการทำ unit test

 

 

 

คุณสมบัติอย่างหนึ่งของ MVP คือจะมีการ dispatch ได้ในลักษณะ 2 ทาง ยกตัวอย่างเช่น ถ้าผู้ใช้กดปุ่ม "Save" แล้วตัวจัดการเหตุการณ์ (event handler) ทำการส่งต่อไปยังเมธอด "OnSave" ที่ Presenter แล้ว เมื่อการ "save" ทำได้อย่างสมบูรณ์แล้วนั้น ตัว Presenter จะสามารถ call back ไปยัง View ผ่านทาง interface ได้เพื่อให้ View ทำการแสดงผลต่อไปเมื่อ "save" สมบูรณ์แล้ว

MVP ตั้งใจจะเป็น pattern ที่เป็นธรรมชาติมากสำหรับที่จะใช้แยกการแสดงผลใน Web เหตุผลก็คือ View จะถูกสร้างก่อนเสมอ

MVP 2 แบบ

Passive View

View ในรูปแบบนี้จะต้องทำให้โง่มากที่สุด และให้แทบไม่มี logic อยู่เลย ตัว Presenter จะเป็นตัวกลางระหว่าง View และ Model โดยทั้ง View และ Model จะไม่รู้จักกันอย่างสิ้นเชิง ตัว Model อาจจะทำให้เกิด event ได้ แต่ตัว Presenter จะเป็นตัวจัดการแล้วทำการปรับปรุง View ในรูปแบบ Passive View นี้จะไม่มีกลไกการโยงข้อมูลโดยตรง ซึ่ง View จะมีหน้าที่บอก setter properties ให้ Presenter ใช้สำหรับตั้งค่าข้อมูล การจัดการ state จะจัดการที่ Presenter ไม่ใช่ที่ View

ข้อดี surface จะสามารถ test ได้เต็มที่ และแยก View และ Model ได้อย่างสมบูรณ์
ข้อเสีย ต้องทำการโยงข้อมูลเอง

 

Supervising Controller

ในรูปแบบนี้ ตัว Presenter จะเป็นตัวจัดการกับผู้ใช้ ในขณะที่ View จะผูกเข้ากับ Model โดยตรงผ่าน data binding กรณีนี้ งานของ Presenter ก็คือจะส่ง Model ไปให้กับ View เพื่อที่จะ bind กันโดยตัว Presenter จะทำหน้าที่จัดการ logic อื่น ๆ ที่เหลือเช่นการ กดปุ่ม การ navigate เป็นต้น

ข้อดี code น้อย เพราะใช้ data binding
ข้อเสีย surface test ได้ยากเพราะ data binding. View กับ Model รู้จักกัน (more coupling)

 

ที่มา http://sites.google.com/site/chanwit/courses/edp-53-2/mvp

 

Advertisement