Android Firebase Kotlin java Mvp Mvc Mvvm chat
1.0.0
MVC เป็นวิธีการที่สะอาดใน Android ที่วางวิวจากคอนโทรลเลอร์ คอนโทรลเลอร์มีความรับผิดชอบเฉพาะในการอัปเดตโมเดลเมื่อโมเดลได้รับการอัปเดตแล้วจะสามารถแจ้งมุมมองได้จากนั้นมุมมองสามารถอัปเดตได้โดยใช้การโทรกลับที่เหมาะสม MVC แบบดั้งเดิมเป็นที่ที่มี
โมเดล : ทำหน้าที่เป็นแบบจำลองข้อมูล
มุมมอง : ข้อตกลงกับมุมมองกับผู้ใช้ซึ่งอาจเป็น UI
คอนโทรลเลอร์ : ควบคุมการโต้ตอบระหว่างโมเดลและมุมมองโดยที่มุมมองเรียกคอนโทรลเลอร์เพื่ออัปเดตโมเดล มุมมองสามารถเรียกตัวควบคุมหลายตัวได้หากจำเป็น ..
ข้อเสียบางประการของ MVC สามารถเอาชนะได้โดยใช้วิธี MVP ผู้นำเสนอใน MVP มีตรรกะทางธุรกิจทั้งหมดและคลาสนี้อยู่ไกลจากบริบท Android หรือการอ้างอิงที่เกี่ยวข้องกับ Android ซึ่งให้ความยืดหยุ่นในการส่งข้อความทางธุรกิจโดยใช้คลาสผู้นำเสนอในโมดูลทดสอบ การพึ่งพาที่เกี่ยวข้องกับ Android สร้างความซับซ้อนในการทดสอบ ผู้นำเสนอไม่มีการพึ่งพา Android ใด ๆ เช่นบริบทดู ฯลฯ และการอัปเดตแบบจำลองทั้งหมดและคำขอเครือข่ายจะทำผ่านผู้นำเสนอ เมื่อโมเดลได้รับการอัปเดตหรือคำขอเครือข่ายเสร็จสมบูรณ์มุมมองจะได้รับการอัปเดตผ่านผู้นำเสนอโดยใช้การโทรกลับเพื่อดูจากผู้นำเสนอ ไม่มีแบบจำลองและคำขอเครือข่ายสามารถเข้าหามุมมองได้โดยตรง
MVVM เกี่ยวข้องกับวิธีการเชื่อมโยงข้อมูลเพื่อให้รหัสสั้นและลดรหัสการจัดการมุมมองจากคลาส Java รูปแบบการดูมีหน้าที่อัปเดตมุมมองและเมื่อโมเดลมุมมองเชื่อมโยงกับมุมมองแล้วมุมมองจะได้รับการแจ้งเตือนเกี่ยวกับเหตุการณ์การอัปเดตของพวกเขา หากโมเดลได้รับการอัปเดตโดยผู้ใช้คลิกจากนั้นรูปแบบจะส่งการโทรกลับเพื่อดูโมเดลซึ่งอัปเดตมุมมองโดยอัตโนมัติเมื่อเชื่อมโยงกับมุมมอง MVVM ลดขนาดรหัส แต่การใช้งาน MVVM นั้นค่อนข้างยากและเป็นเรื่องยากที่จะแก้ไขข้อบกพร่องของโครงการขนาดใหญ่ตาม MVVM
-
การเลือกสถาปัตยกรรมที่ถูกต้อง สำหรับโครงการเกี่ยวข้องกับความเข้าใจของโมดูลที่จำเป็นต้องพัฒนา ฟังก์ชันบางอย่างใช้งานได้ดีใน MVC บางอย่างมี MVP และบางอย่างด้วย MVVM มันค่อนข้างยากที่จะดีบักโครงการที่ทำใน MVVM เป็นพิเศษซึ่งไม่มีการไหลของข้อมูลด้านเดียวเนื่องจากข้อมูลที่มีผลผูกพันและข้อมูลสด หากแอปพลิเคชันได้รับกระแสข้อมูลอย่างต่อเนื่องจากแหล่งที่มาต้องการ UI-update ปกติและมีการสื่อสารด้านเดียว (80–90%) (เช่นอุปกรณ์อิเล็กทรอนิกส์ที่ส่งบันทึกไปยังแอพ Android) เช่นแอพเซลล์ แสงอาทิตย์ แอพอินเวอร์เตอร์หรือการตรวจสอบสถานะของอุปกรณ์อื่น ๆ การดีบักแอปพลิเคชัน MVVM เหล่านี้อาจเป็นเรื่องง่ายเนื่องจาก การไหลของข้อมูลที่สำคัญคือด้านเดียว
MVP เป็นวิธีการที่ดีสำหรับการเขียนโครงการ Android เมื่อเรามีความกังวลเกี่ยวกับการทดสอบการทดสอบหน่วยตรรกะทางธุรกิจ WRT ผ่านเฟรมเวิร์กการทดสอบ Java (ไม่ใช่ Android) เนื่องจาก กรอบการทดสอบ Java จะแก้ไขการพึ่งพา Java และเลเยอร์ผู้นำเสนอที่สะอาดได้นั้นเป็นอิสระจากการพึ่งพาที่เกี่ยวข้องกับ Android เช่นบริบทการแชร์เฟอร์เฟอร์หรือ com.android อื่น ๆ * บรรจุุภัณฑ์. ข้อเสียเปรียบของ MVP คือการเขียน โค้ดพิเศษ 20-25% พร้อมฟังก์ชันการทำงานเดียวกันที่เขียนใน MVC หรือ MVVM MVP นั้นดีถ้าคุณสนใจกรณีทดสอบและการทดสอบหน่วยของโมดูล สำหรับ MVP ที่ใช้ชุดทดสอบ Java เพียงทำอินสแตนซ์ของผู้นำเสนอและเรียกใช้ฟังก์ชั่นทดสอบ
เช่น: ผู้นำเสนอใหม่ (). TestsomeFunction ()
MVC เป็นเทคนิคที่ใช้กันอย่างแพร่หลายใน Android Google เองเขียนว่าเป็นที่เก็บใน MVC เป็นเวลาหลายปี วันนี้ Google กำลังใช้ MVVM สำหรับที่เก็บ GitHub เนื่องจาก repo เหล่านี้มีขนาดเล็กและเป็นตัวอย่างหลัก แอปพลิเคชัน MVC สามารถทดสอบผ่านเฟรมเวิร์กการทดสอบ Android ที่ไม่ได้ใช้เครื่องมือทดสอบเฉพาะ Java เนื่องจากขาดการอ้างอิงของ com.android * แพ็คเกจ ในเครื่องมือเฉพาะ Java
ตัวอย่าง :
หมายเหตุ : ไม่มีสถาปัตยกรรมเดียวที่ดีที่สุดของทั้งหมด หากมีอยู่คนหนึ่งจะไม่จำเป็นต้องเรียนรู้สถาปัตยกรรมอื่น ๆ ทางเลือกของสถาปัตยกรรมที่ถูกต้องขึ้นอยู่กับปัจจัยหลายประการเช่นข้อกำหนดเบื้องต้นการไหลของข้อมูลความสามารถในการปรับขนาดการบำรุงรักษาการอัปเดต (CRS) ข้อกำหนดการทดสอบ
ยกเว้นสถาปัตยกรรม Android ทั้งสามนี้มีสถาปัตยกรรมอีกหนึ่งชื่อว่า "MVI - Model View Intent" นี่ไม่ได้รับความนิยมมากในหมู่นักพัฒนา Android โปรดตรวจสอบลิงค์นี้หากคุณสนใจ MVI
https://github.com/saksham24/android-simple-mvi-pattern-with-mvp-mvvm-collaboration
