การเรียนรู้สถาปัตยกรรมการพัฒนา Android (MVC, MVP, MVVM, MVI)

May 12 2023

มาดำดิ่งสู่โลกของสถาปัตยกรรมการพัฒนา Android กันเถอะ ในคู่มือฉบับสมบูรณ์นี้ เราจะสำรวจรูปแบบสถาปัตยกรรม เฟรมเวิร์ก และแนวทางปฏิบัติที่ดีที่สุดต่างๆ เพื่อช่วยคุณสร้างแอปพลิเคชัน Android ที่มีประสิทธิภาพ ปรับขนาดได้ และบำรุงรักษาได้ ไม่ว่าคุณจะเป็นนักพัฒนามือใหม่หรือนักพัฒนาที่มีประสบการณ์ บล็อกนี้เป็นแหล่งข้อมูลสำหรับการทำความเข้าใจและนำสถาปัตยกรรมการพัฒนา Android ไปใช้งาน

ทำให้เข้าใจสถาปัตยกรรม Android ได้ง่ายขึ้น: บทนำที่ครอบคลุม

สถาปัตยกรรม Android หมายถึงการออกแบบและโครงสร้างของแอปพลิเคชัน Android ซึ่งรวมถึงลักษณะที่ส่วนประกอบต่างๆ ของแอปพลิเคชันมีปฏิสัมพันธ์ซึ่งกันและกัน การไหลของข้อมูลภายในแอปพลิเคชัน และวิธีการจัดการกับการโต้ตอบของผู้ใช้ สถาปัตยกรรมที่ออกแบบอย่างดีมีความสำคัญอย่างยิ่งต่อการสร้างแอปพลิเคชัน Android ที่มีประสิทธิภาพ ปรับขนาดได้ และบำรุงรักษาได้

สถาปัตยกรรม Android ที่มีประสิทธิภาพไม่เพียงแต่ช่วยเพิ่มประสิทธิภาพและความเสถียรของแอปเท่านั้น แต่ยังทำให้กระบวนการพัฒนาง่ายขึ้น และเพิ่มคุณสมบัติใหม่หรือเปลี่ยนแปลงในอนาคตได้ง่ายขึ้น

สถาปัตยกรรม MVC (Model-View-Controller):

MVC (Model-View-Controller) เป็นหนึ่งในรูปแบบสถาปัตยกรรมที่ใช้กันอย่างแพร่หลายในการพัฒนาซอฟต์แวร์ รวมถึงการพัฒนาแอพ Android แต่ละองค์ประกอบมีหน้าที่รับผิดชอบของตนเองและมีส่วนสนับสนุนโครงสร้างและฟังก์ชันการทำงานโดยรวมของแอปพลิเคชัน

ข้อผิดพลาดของ MVC (Model-View-Controller)

Massive Controllers : ใน MVC ตัวควบคุมมีหน้าที่จัดการอินพุตของผู้ใช้และอัปเดตโมเดลและดูตามนั้น อย่างไรก็ตาม เมื่อแอปพลิเคชันเติบโตขึ้น คอนโทรลเลอร์มีแนวโน้มที่จะสะสมความรับผิดชอบจำนวนมากและอาจกลายเป็นป่องได้ สิ่งนี้นำไปสู่ความยากลำบากในการบำรุงรักษาและทดสอบตรรกะของคอนโทรลเลอร์
View-Controller Dependency : ใน MVC มุมมองและคอนโทรลเลอร์เชื่อมต่อกันแน่น ซึ่งหมายความว่ามุมมองจะสื่อสารโดยตรงกับคอนโทรลเลอร์ สิ่งนี้สามารถนำไปสู่สถานการณ์ที่มุมมองมีการพึ่งพาอย่างมากในการนำไปใช้งานเฉพาะของคอนโทรลเลอร์ ทำให้ยากต่อการนำกลับมาใช้ใหม่หรือแก้ไขมุมมองโดยอิสระ
ขาดการแยกข้อกังวล : MVC ไม่ได้บังคับใช้การแยกข้อกังวลอย่างเข้มงวดระหว่างรุ่น มุมมอง และตัวควบคุม ซึ่งอาจส่งผลให้เกิดการผสมตรรกะทางธุรกิจกับตรรกะการนำเสนอ ซึ่งนำไปสู่โค้ดที่ยากต่อการเข้าใจ บำรุงรักษา และทดสอบ
ความสามารถในการทดสอบที่จำกัด : เนื่องจากการต่อพ่วงแน่นระหว่างส่วนประกอบต่างๆ การทดสอบส่วนประกอบแต่ละชิ้นแบบแยกส่วนจึงกลายเป็นเรื่องท้าทาย การทดสอบคอนโทรลเลอร์มักต้องมีมุมมองและแบบจำลอง ทำให้ยากต่อการเขียนการทดสอบหน่วยที่ครอบคลุม

สร้างคลาสแบบจำลองที่แสดงข้อมูลของแอปพลิเคชันของคุณ คลาสนี้ควรมีตรรกะทางธุรกิจและวิธีการเข้าถึงข้อมูล
สร้างคลาสมุมมองที่แสดง UI ของแอปพลิเคชันของคุณ คลาสนี้ควรรับผิดชอบในการแสดงข้อมูลและจัดการอินพุตของผู้ใช้เท่านั้น
สร้างคลาสคอนโทรลเลอร์ที่ทำหน้าที่เป็นสื่อกลางระหว่างโมเดลและมุมมอง คลาสนี้ควรจัดการอินพุตของผู้ใช้ อัปเดตโมเดล และอัปเดตมุมมอง
เชื่อมต่อโมเดล มุมมอง และคอนโทรลเลอร์โดยใช้รูปแบบการออกแบบ เช่น สังเกตการณ์ ซึ่งมุมมองจะสังเกตการเปลี่ยนแปลงในโมเดล และคอนโทรลเลอร์จะอัปเดตทั้งโมเดลและมุมมอง

คลาสโมเดล (เช่น MyModel.java):

public class MyModel {
    private String mData;

    public String getData() {
        return mData;
    }

    public void setData(String data) {
        mData = data;
    }
}

public class MyView extends Activity {
    private TextView mTextView;
    private Button mButton;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_my_view);

        mTextView = (TextView) findViewById(R.id.textview);
        mButton = (Button) findViewById(R.id.button);

        mButton.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                // Notify the controller of the user input
                mController.onUserAction();
            }
        });
    }

    // Update the view with the data from the model
    public void updateView(String data) {
        mTextView.setText(data);
    }
}

public class MyController {
    private MyModel mModel;
    private MyView mView;

    public MyController(MyModel model, MyView view) {
        mModel = model;
        mView = view;
    }

    // Handle user input
    public void onUserAction() {
        // Update the model with new data
        mModel.setData("Hello, World!");

        // Notify the view to update with the new data from the model
        mView.updateView(mModel.getData());
    }
}

MVP (Model-View-Presenter) เป็นอีกหนึ่งรูปแบบสถาปัตยกรรมที่ใช้กันทั่วไปในการพัฒนา Android เป็นรูปแบบของ MVC ที่มีจุดมุ่งหมายเพื่อแยกข้อกังวลและปรับปรุงการจัดระเบียบรหัส MVP ประกอบด้วยสามองค์ประกอบหลัก:

โมเดล : โมเดลแสดงถึงข้อมูลและตรรกะทางธุรกิจของแอปพลิเคชัน ซึ่งอาจรวมถึงการดึงข้อมูลจากฐานข้อมูล คำขอเครือข่าย หรือการดำเนินการอื่นๆ ที่เกี่ยวข้องกับข้อมูล
มุมมอง : มุมมองรับผิดชอบในการแสดงส่วนต่อประสานกับผู้ใช้และรับอินพุตจากผู้ใช้ ควรเป็นแบบพาสซีฟที่สุดเท่าที่จะเป็นไปได้ ส่งต่อการกระทำของผู้ใช้ไปยังผู้นำเสนอเท่านั้น และอัปเดต UI ตามคำแนะนำของผู้นำเสนอ
ผู้นำเสนอ : ผู้นำเสนอทำหน้าที่เป็นคนกลางระหว่างแบบจำลองและมุมมอง รับอินพุตของผู้ใช้จากมุมมอง โต้ตอบกับโมเดลเพื่อดึงและจัดการข้อมูล และอัปเดตมุมมองด้วยผลลัพธ์ ผู้นำเสนอยังมีตรรกะการนำเสนอของแอปพลิเคชัน

การแยกข้อกังวล : MVP ส่งเสริมการแยกข้อกังวลที่ชัดเจนระหว่างส่วนประกอบต่างๆ ของแอปพลิเคชัน แบบจำลองแสดงถึงข้อมูลและตรรกะทางธุรกิจ มุมมองมีหน้าที่รับผิดชอบในการแสดง UI และผู้นำเสนอทำหน้าที่เป็นตัวกลางระหว่างแบบจำลองและมุมมอง การแยกส่วนนี้ทำให้ codebase เป็นแบบแยกส่วนมากขึ้น เข้าใจและบำรุงรักษาได้ง่ายขึ้น
ความสามารถในการทดสอบ : MVP ปรับปรุงความสามารถในการทดสอบเนื่องจากตรรกะทางธุรกิจอยู่ใน Presenter ซึ่งเป็นคลาส Java หรือ Kotlin ธรรมดาที่ไม่มีการพึ่งพาส่วนประกอบเฉพาะของ Android ซึ่งช่วยให้การทดสอบหน่วยของผู้นำเสนอทำได้ง่ายขึ้น เนื่องจากสามารถทดสอบโดยไม่ขึ้นกับเฟรมเวิร์ก Android ด้วยการแยกตรรกะทางธุรกิจออกจากเฟรมเวิร์ก Android การเขียนกรณีทดสอบและตรวจสอบความถูกต้องของแอปพลิเคชันจะง่ายขึ้น
การใช้รหัสซ้ำ : ด้วย MVP การแยกข้อกังวลช่วยให้สามารถใช้รหัสซ้ำได้ดีขึ้น Presenter ไม่มีรหัสเฉพาะของ Android และสามารถใช้ซ้ำได้บนแพลตฟอร์มหรือโมดูลต่างๆ สิ่งนี้อาจเป็นประโยชน์หากคุณมีการใช้งาน UI หลายแบบหรือหากคุณวางแผนที่จะแบ่งปันตรรกะทางธุรกิจหลักกับโครงการอื่นๆ
การบำรุงรักษา : ด้วยการแยกความรับผิดชอบของส่วนประกอบต่างๆ MVP ทำให้ codebase ง่ายต่อการบำรุงรักษา ปรับปรุงการจัดระเบียบรหัสและความสามารถในการอ่าน ทำให้นักพัฒนาเข้าใจและแก้ไขแอปพลิเคชันได้ง่ายขึ้นเมื่อเติบโตขึ้นเมื่อเวลาผ่านไป
ความสามารถในการปรับขนาด : MVP ให้โครงสร้างที่ปรับขนาดได้สำหรับแอปพลิเคชัน Android เมื่อความซับซ้อนของแอปพลิเคชันเพิ่มขึ้น การแยกข้อกังวลที่ชัดเจนจะช่วยให้สามารถขยายและแก้ไขส่วนประกอบแต่ละส่วนได้ง่ายขึ้น วิธีการแบบแยกส่วนนี้ช่วยให้เพิ่มคุณสมบัติใหม่ แก้ไขจุดบกพร่อง หรือทำการเปลี่ยนแปลงได้ง่ายขึ้นโดยไม่ส่งผลกระทบต่อส่วนอื่นๆ ของแอปพลิเคชัน
ความยืดหยุ่น : MVP มอบความยืดหยุ่นในแง่ของการใช้งาน UI เนื่องจาก Presenter ทำหน้าที่เป็นตัวกลาง การสลับหรืออัปเดตเลเยอร์ UI จึงง่ายขึ้นโดยไม่ส่งผลกระทบต่อตรรกะทางธุรกิจ ตัวอย่างเช่น คุณสามารถแทนที่ UI ที่อิงตามกิจกรรมด้วย UI ที่อิงตามแฟรกเมนต์ หรือแม้แต่สนับสนุนการใช้งาน UI หลายรายการโดยไม่ต้องแก้ไขฟังก์ชันการทำงานหลัก

การมีเพศสัมพันธ์ที่แน่นแฟ้นระหว่างมุมมองและผู้นำเสนอ: หนึ่งในหลุมพรางหลักของ MVP คือการมีเพศสัมพันธ์ที่แน่นระหว่างมุมมองและผู้นำเสนอ มุมมองมีการอ้างอิงโดยตรงถึงผู้นำเสนอ ซึ่งอาจนำไปสู่ความซับซ้อนที่เพิ่มขึ้นและขัดขวางความสามารถในการทดสอบ ใน MVVM View และ ViewModel จะเชื่อมโยงกันแบบหลวมๆ มากขึ้น ส่งเสริมการแยกข้อกังวลที่ดีขึ้น
การผูกข้อมูลด้วยตนเอง: ใน MVP มุมมองมีหน้าที่รับผิดชอบในการผูกข้อมูลจากโมเดลกับองค์ประกอบ UI การผูกข้อมูลด้วยตนเองนี้อาจยุ่งยากและเกิดข้อผิดพลาดได้ง่าย โดยเฉพาะใน UI ที่ซับซ้อน ในทางกลับกัน MVVM นำเสนอเฟรมเวิร์กการเชื่อมโยงข้อมูล (เช่น Data Binding หรือ LiveData) ที่ทำให้กระบวนการนี้เป็นไปโดยอัตโนมัติ ลดรหัสสำเร็จรูปและปรับปรุงประสิทธิภาพ
ความรับผิดชอบของผู้นำเสนอมากเกินไป: ใน MVP ผู้นำเสนอมักจะอ้วนและมีความรับผิดชอบมากเกินไป ทำหน้าที่เป็นตัวกลางระหว่างโมเดลและมุมมอง จัดการทั้งตรรกะทางธุรกิจและการโต้ตอบ UI สิ่งนี้อาจนำไปสู่การละเมิดหลักการความรับผิดชอบเดียว (SRP) MVVM แก้ไขปัญหานี้โดยแนะนำ ViewModel ซึ่งได้รับการออกแบบมาโดยเฉพาะเพื่อจัดการตรรกะที่เกี่ยวข้องกับ UI และการดำเนินการเกี่ยวกับข้อมูล
ขาดการจัดการสถานะ: MVP ไม่ได้ให้แนวทางที่เป็นมาตรฐานสำหรับการจัดการสถานะของมุมมอง เป็นผลให้นักพัฒนามักจะหันไปใช้เทคนิคการจัดการสถานะด้วยตนเอง ซึ่งนำไปสู่ความไม่สอดคล้องกันและข้อบกพร่องที่อาจเกิดขึ้น MVVM รวมแนวคิดการเขียนโปรแกรมเชิงโต้ตอบ ซึ่งช่วยให้การจัดการสถานะดีขึ้นผ่านการผูกข้อมูลและสิ่งที่สังเกตได้
การจัดการวงจรชีวิตของมุมมอง: ใน MVP การจัดการวงจรชีวิตของมุมมองจะกลายเป็นความรับผิดชอบของผู้นำเสนอ สิ่งนี้อาจทำให้เกิดความซับซ้อน โดยเฉพาะอย่างยิ่งเมื่อต้องจัดการกับการเปลี่ยนแปลงการกำหนดค่าหรือการจัดการเหตุการณ์วงจรชีวิตของ View MVVM ใช้ประโยชน์จากส่วนประกอบที่รับรู้วงจรชีวิตซึ่งจัดเตรียมโดยส่วนประกอบสถาปัตยกรรม Android ทำให้การจัดการวงจรชีวิตของ View ง่ายขึ้น
ความท้าทายในการทดสอบ: แม้ว่า MVP จะส่งเสริมความสามารถในการทดสอบที่ดีขึ้นเมื่อเทียบกับวิธีการแบบเดิม แต่ก็ยังสามารถนำเสนอความท้าทายเมื่อพูดถึงหน่วยทดสอบการโต้ตอบของมุมมองและผู้นำเสนอ การประกบกันแน่นระหว่าง View และ Presenter อาจทำให้แยกและทดสอบส่วนประกอบแต่ละชิ้นได้ยาก

สร้างโมเดล:โมเดลแสดงถึงข้อมูลและตรรกะทางธุรกิจ ในกรณีนี้ เราจะสร้างUserคลาสข้อมูล อย่างง่าย

data class User(val username: String, val password: String)

interface ILoginView {
    fun showProgress()
    fun hideProgress()
    fun showError(message: String)
    fun navigateToHome()
}

class LoginPresenter(private val view: ILoginView) : ILoginPresenter {

    override fun login(username: String, password: String) {
        view.showProgress()

        // Perform authentication logic
        val user = User("admin", "password")
        if (username == user.username && password == user.password) {
            // Successful login
            view.hideProgress()
            view.navigateToHome()
        } else {
            // Invalid credentials
            view.hideProgress()
            view.showError("Invalid username or password")
        }
    }
}

class LoginActivity : AppCompatActivity(), ILoginView {

    private lateinit var presenter: ILoginPresenter

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_login)

        presenter = LoginPresenter(this)

        // Set up login button click listener
        loginButton.setOnClickListener {
            val username = usernameEditText.text.toString()
            val password = passwordEditText.text.toString()
            presenter.login(username, password)
        }
    }

    override fun showProgress() {
        progressBar.visibility = View.VISIBLE
    }

    override fun hideProgress() {
        progressBar.visibility = View.GONE
    }

    override fun showError(message: String) {
        Toast.makeText(this, message, Toast.LENGTH_SHORT).show()
    }

    override fun navigateToHome() {
        val intent = Intent(this, HomeActivity::class.java)
        startActivity(intent)
        finish()
    }
}

interface ILoginPresenter {
    fun login(username: String, password: String)
}

MVVM (Model-View-ViewModel) เป็นรูปแบบสถาปัตยกรรมที่ใช้ในการพัฒนา Android เป็นวิวัฒนาการของรูปแบบ MVC (Model-View-Controller) และ MVP (Model-View-Presenter) ซึ่งออกแบบมาเพื่อแก้ไขข้อจำกัดบางประการและให้ประโยชน์เพิ่มเติม

ใน MVVM แอปพลิเคชันจะแบ่งออกเป็นสามองค์ประกอบหลัก:

โมเดล : โมเดลแสดงถึงข้อมูลและตรรกะทางธุรกิจของแอปพลิเคชัน สรุปแหล่งข้อมูล เช่น ฐานข้อมูล บริการเว็บ หรือไฟล์ในเครื่อง และจัดเตรียมวิธีการโต้ตอบและจัดการข้อมูล
มุมมอง : มุมมองรับผิดชอบในการแสดงส่วนติดต่อผู้ใช้และจัดการการโต้ตอบของผู้ใช้ โดยทั่วไปจะประกอบด้วยกิจกรรม ส่วนย่อย หรือมุมมองแบบกำหนดเอง อย่างไรก็ตาม ใน MVVM มุมมองไม่ควรมีตรรกะทางธุรกิจใดๆ หรือเข้าถึงข้อมูลโดยตรง แต่จะผูกกับ ViewModel เพื่อแสดงข้อมูลและแจ้ง ViewModel เกี่ยวกับการกระทำของผู้ใช้
ViewModel : ViewModel ทำหน้าที่เป็นตัวกลางระหว่าง View และ Model ประกอบด้วยตรรกะการนำเสนอและเก็บข้อมูลที่มุมมองต้องการแสดง ViewModel แสดงเมธอดและคุณสมบัติที่ View สามารถผูกได้ โดยจะดึงข้อมูลจากโมเดล จัดเตรียมและประมวลผล และอัปเดตการดูผ่านการเชื่อมโยงข้อมูล ViewModel ยังจัดการการกระทำของผู้ใช้จาก View และสื่อสารกับ Model เพื่อดำเนินการกับข้อมูล

การแยกข้อกังวล: MVVM ส่งเสริมการแยกข้อกังวลที่ชัดเจนระหว่าง View, ViewModel และ Model การแยกนี้ช่วยให้สามารถบำรุงรักษาและทดสอบโค้ดเบสได้ดีขึ้น
การผูกข้อมูล: MVVM ใช้กรอบการผูกข้อมูลเช่น Android Data Binding หรือ LiveData และ ViewModels ของ Jetpack เพื่อสร้างการเชื่อมต่อระหว่าง View และ ViewModel สิ่งนี้ทำให้สามารถอัปเดต UI โดยอัตโนมัติเมื่อข้อมูลเปลี่ยนแปลงใน ViewModel ซึ่งช่วยลดรหัสสำเร็จรูปที่จำเป็นสำหรับการอัปเดต UI
ความสามารถในการทดสอบ: MVVM ปรับปรุงความสามารถในการทดสอบโดยทำให้มั่นใจว่าตรรกะทางธุรกิจอยู่ใน ViewModel ซึ่งเป็นอิสระจากเฟรมเวิร์กของ Android การแยกนี้ช่วยให้การทดสอบหน่วยของ ViewModel ทำได้ง่ายขึ้น เนื่องจากสามารถทดสอบได้โดยไม่ต้องอาศัยส่วนประกอบของ Android
การเขียนโปรแกรมเชิงโต้ตอบ: MVVM ใช้ประโยชน์จากหลักการเขียนโปรแกรมเชิงโต้ตอบ โดยที่การเปลี่ยนแปลงข้อมูลหรือการโต้ตอบของผู้ใช้จะถือว่าเป็นสตรีมของเหตุการณ์ สิ่งนี้ช่วยให้การอัปเดต UI ตอบสนองและยืดหยุ่นมากขึ้น เนื่องจาก View ตอบสนองต่อการเปลี่ยนแปลงในข้อมูลของ ViewModel โดยไม่มีการเรียกกลับที่ชัดเจนหรือการซิงโครไนซ์ด้วยตนเอง
การรับรู้วงจรชีวิต: ส่วนประกอบสถาปัตยกรรม Android ที่ใช้กันทั่วไปใน MVVM มีส่วนประกอบที่รับรู้วงจรชีวิต เช่น LiveData และ ViewModel คอมโพเนนต์เหล่านี้ออกแบบมาเพื่อจัดการกับเหตุการณ์วงจรชีวิตของ Android เพื่อให้แน่ใจว่า ViewModel ยังคงอยู่ระหว่างการเปลี่ยนแปลงการกำหนดค่า และป้องกันปัญหาทั่วไป เช่น การรั่วไหลของหน่วยความจำ
โดยรวมแล้ว MVVM เป็นรูปแบบสถาปัตยกรรมที่ได้รับความนิยมในการพัฒนา Android เนื่องจากมีข้อดีในการแยกข้อกังวล ความสามารถในการทดสอบ การผูกข้อมูล และการรับรู้วงจรชีวิต ช่วยให้นักพัฒนาสร้างแอปพลิเคชันที่แข็งแกร่งและบำรุงรักษาได้ด้วยการจัดเตรียมโครงสร้างที่ชัดเจนสำหรับการจัดระเบียบโค้ดและจัดการการอัปเดต UI

ความซับซ้อนและเส้นโค้งแห่งการเรียนรู้: การใช้ MVVM สามารถทำให้เกิดความซับซ้อนในระดับที่สูงขึ้นเมื่อเทียบกับรูปแบบที่เรียบง่ายกว่า เช่น MVC หรือ MVP เลเยอร์และส่วนประกอบเพิ่มเติม เช่น การผูกข้อมูล อาจต้องใช้ช่วงการเรียนรู้สำหรับนักพัฒนาที่ยังใหม่กับ MVVM อาจใช้เวลาสักครู่เพื่อทำความเข้าใจแนวคิดและแนวทางปฏิบัติที่ดีที่สุดที่เกี่ยวข้องกับ MVVM
การใช้ Data Binding มากเกินไป: Data Binding เป็นคุณสมบัติหลักใน MVVM ที่ช่วยให้สามารถซิงโครไนซ์ข้อมูลระหว่าง View และ ViewModel ได้โดยอัตโนมัติ อย่างไรก็ตาม สิ่งสำคัญคือต้องใช้การเชื่อมโยงข้อมูลอย่างรอบคอบ การใช้การเชื่อมโยงข้อมูลมากเกินไป เช่น การผูกคุณสมบัติมากเกินไปหรือนิพจน์ที่ซับซ้อน อาจส่งผลต่อประสิทธิภาพและทำให้โค้ดดูแลรักษายากขึ้น
กรณีการใช้งานที่เรียบง่ายซึ่งซับซ้อนมากเกินไป: MVVM เป็นรูปแบบอเนกประสงค์ที่เหมาะสำหรับการใช้งานที่ซับซ้อน แต่อาจไม่จำเป็นสำหรับกรณีการใช้งานที่เรียบง่ายกว่า การใช้ MVVM กับแอปพลิเคชันขนาดเล็กและตรงไปตรงมาอาจทำให้เกิดความซับซ้อนโดยไม่จำเป็น สิ่งสำคัญคือต้องพิจารณาขนาดและข้อกำหนดของโครงการก่อนที่จะเลือก MVVM
ขนาดไฟล์และรหัสที่เพิ่มขึ้น: MVVM สามารถนำไปสู่การเพิ่มจำนวนไฟล์และขนาดของรหัสเมื่อเทียบกับรูปแบบที่เรียบง่ายกว่า นี่เป็นเพราะการแนะนำคลาส ViewModel ที่แยกจากกัน และความต้องการนิพจน์การโยงและไฟล์โครงร่าง XML โครงการขนาดใหญ่ที่มีคุณลักษณะและหน้าจอมากมายอาจพบการขยายตัวของโค้ดเบส ซึ่งอาจส่งผลกระทบต่อการบำรุงรักษาโค้ด
ความท้าทายในการเชื่อมโยงข้อมูลแบบสองทาง: การเชื่อมโยงข้อมูลแบบสองทาง ซึ่งการเปลี่ยนแปลงใน View จะถูกส่งกลับไปที่ ViewModel โดยอัตโนมัติ อาจทำให้เกิดความซับซ้อนได้ การจัดการการตรวจสอบอินพุตของผู้ใช้ การจัดการการแปลงข้อมูลที่ซับซ้อน หรือการจัดการกับประเภทข้อมูลแบบกำหนดเองอาจเป็นเรื่องที่ท้าทายเมื่อใช้การเชื่อมโยงข้อมูลแบบสองทาง ต้องมีการพิจารณาอย่างรอบคอบและนำไปใช้เพื่อให้แน่ใจว่าข้อมูลมีความสมบูรณ์และหลีกเลี่ยงข้อบกพร่องที่อาจเกิดขึ้น

ตั้งค่าการพึ่งพาที่จำเป็น:-ในไฟล์ build.gradle ของโครงการของคุณ ให้เพิ่มการพึ่งพาที่จำเป็น ตัวอย่างเช่น คุณสามารถรวมไลบรารีส่วนประกอบสถาปัตยกรรม Android เช่น LiveData และ ViewModel:

dependencies {  
  // Other dependencies 
  implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:<version>"
  implementation "androidx.lifecycle:lifecycle-livedata-ktx:<version>"
 }

data class Item(val name: String)

import androidx.lifecycle.MutableLiveData
import androidx.lifecycle.ViewModel

class ItemViewModel : ViewModel() {
    val itemList: MutableLiveData<List<Item>> = MutableLiveData()

    fun loadItems() {
        // Simulate loading items from a data source
        val items = listOf(Item("Item 1"), Item("Item 2"), Item("Item 3"))
        itemList.value = items
    }
}

import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
import androidx.lifecycle.Observer
import androidx.lifecycle.ViewModelProvider
import com.example.mvvmexample.databinding.ActivityItemListBinding

class ItemListActivity : AppCompatActivity() {
    private lateinit var binding: ActivityItemListBinding
    private lateinit var viewModel: ItemViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityItemListBinding.inflate(layoutInflater)
        setContentView(binding.root)

        viewModel = ViewModelProvider(this).get(ItemViewModel::class.java)

        val adapter = ItemAdapter()
        binding.itemListRecyclerView.adapter = adapter

        viewModel.itemList.observe(this, Observer { items ->
            items?.let {
                adapter.setItems(it)
            }
        })

        viewModel.loadItems()
    }
}

สร้างอะแดปเตอร์ : - อะแดปเตอร์มีหน้าที่รับผิดชอบในการผูกข้อมูลกับส่วนประกอบ UI สร้างItemAdapterคลาสที่ขยายRecyclerView.Adapter.

import android.view.LayoutInflater
import android.view.ViewGroup
import androidx.recyclerview.widget.RecyclerView
import com.example.mvvmexample.databinding.ItemListItemBinding

class ItemAdapter : RecyclerView.Adapter<ItemAdapter.ItemViewHolder>() {
    private var items: List<Item> = emptyList()

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ItemViewHolder {
        val inflater = LayoutInflater.from(parent.context)
        val binding = ItemListItemBinding.inflate(inflater, parent, false)
        return ItemViewHolder(binding)
    }

    override fun onBindViewHolder(holder: ItemViewHolder, position: Int) {
        holder.bind(items[position])
    }

    override fun getItemCount(): Int = items.size

    fun setItems(newItems: List<Item>) {
        items = newItems
        notifyDataSetChanged()
    }

    inner class ItemViewHolder(private val binding: ItemListItemBinding) :
        RecyclerView.ViewHolder(binding.root) {
        fun bind(item: Item) {
            binding.itemNameTextView.text = item.name
        }
    }
}

นี่คือการใช้งานพื้นฐานของ MVVM ในโครงการ Android โดยใช้ Kotlin แสดงการแยกข้อกังวลระหว่าง View, ViewModel และ Model รวมถึงการใช้ LiveData เพื่อสังเกตการเปลี่ยนแปลงในข้อมูลของ ViewModel และอัปเดต UI ตามนั้น

MVI (Model-View-Intent) เป็นอีกหนึ่งรูปแบบสถาปัตยกรรม :-

MVI (Model-View-Intent) เป็นรูปแบบสถาปัตยกรรมที่ใช้ในการพัฒนาแอพ Android เป็นการเปลี่ยนแปลงของรูปแบบ MVC (Model-View-Controller) และ MVP (Model-View-Presenter) ที่เป็นที่นิยม ซึ่งออกแบบมาเพื่อแก้ไขข้อจำกัดบางประการ และให้แนวทางที่ตอบสนองและคาดเดาได้มากขึ้นในการสร้างส่วนติดต่อผู้ใช้

ใน MVI โฟลว์ของแอปพลิเคชันจะหมุนรอบองค์ประกอบหลักสามส่วน:

โมเดล : โมเดลแสดงถึงสถานะของแอปพลิเคชันและประกอบด้วยข้อมูลและตรรกะทางธุรกิจ มันไม่เปลี่ยนรูปและทำหน้าที่เป็นแหล่งเดียวของความจริง โมเดลแสดงถึงสถานะปัจจุบันของ UI และได้รับการอัปเดตตามการโต้ตอบของผู้ใช้หรือเหตุการณ์ภายนอก
มุมมอง : มุมมองมีหน้าที่ในการแสดง UI และแสดงสถานะปัจจุบันแก่ผู้ใช้ เป็นองค์ประกอบแบบพาสซีฟและไม่มีตรรกะทางธุรกิจใดๆ มุมมองได้รับสถานะจากแบบจำลองและแสดงผลตามนั้น นอกจากนี้ยังจับการโต้ตอบของผู้ใช้และแปลงเป็นความตั้งใจที่จะส่งไปยังผู้นำเสนอ
เจตนา : เจตนาแสดงถึงความตั้งใจหรือการกระทำของผู้ใช้ เป็นเหตุการณ์ที่บันทึกการโต้ตอบของผู้ใช้หรือเหตุการณ์ของระบบ และส่งจากมุมมองไปยังผู้นำเสนอ Intents อธิบายถึงสิ่งที่ผู้ใช้ต้องการทำหรือการเปลี่ยนแปลงที่พวกเขาต้องการทำในสถานะแอปพลิเคชัน

View รับสถานะปัจจุบันจาก Model และแสดงผลให้กับผู้ใช้
การโต้ตอบของผู้ใช้ในมุมมองจะสร้างความตั้งใจ ซึ่งจะถูกส่งไปยังผู้นำเสนอ
ผู้นำเสนอได้รับเจตนา ประมวลผล และสร้างสถานะใหม่ตามสถานะปัจจุบันและเจตนา ผู้นำเสนอมีหน้าที่รับผิดชอบในการอัปเดตโมเดลด้วยสถานะใหม่
สถานะที่อัปเดตในโมเดลจะทริกเกอร์การอัปเดตในมุมมอง และวงจรจะดำเนินต่อไป

การไหลของข้อมูลแบบทิศทางเดียว: MVI บังคับใช้การไหลของข้อมูลและเหตุการณ์แบบทิศทางเดียว ซึ่งช่วยลดความยุ่งยากในการทำความเข้าใจและแก้ไขจุดบกพร่องของพฤติกรรมของแอปพลิเคชัน ให้ลำดับการแปลงข้อมูลที่ชัดเจน และทำให้ง่ายต่อการให้เหตุผลเกี่ยวกับการเปลี่ยนแปลงสถานะ
โมเดลที่ไม่เปลี่ยนรูป: โมเดลใน MVI นั้นเปลี่ยนรูปไม่ได้ หมายความว่าไม่สามารถแก้ไขได้โดยตรง อินสแตนซ์ใหม่ของโมเดลจะถูกสร้างขึ้นพร้อมกับการเปลี่ยนแปลงสถานะแต่ละครั้ง การเปลี่ยนแปลงไม่ได้นี้ทำให้มั่นใจได้ถึงความสอดคล้องและคาดการณ์สถานะของแอปพลิเคชันได้
ความสามารถในการทดสอบ: MVI ส่งเสริมความสามารถในการทดสอบโดยแยกส่วนประกอบ View, Model และ Presenter ความไม่เปลี่ยนรูปของโมเดลและการไหลแบบทิศทางเดียวทำให้เขียนการทดสอบหน่วยสำหรับแต่ละส่วนประกอบแยกจากกันได้ง่ายขึ้น
การเขียนโปรแกรมเชิงโต้ตอบ: MVI สอดคล้องกับหลักการเขียนโปรแกรมเชิงโต้ตอบและไลบรารี การเขียนโปรแกรมเชิงโต้ตอบช่วยให้สามารถเขียนและแปลงสตรีมของเหตุการณ์และข้อมูล ซึ่งสามารถใช้ประโยชน์จาก MVI เพื่อจัดการกับการโต้ตอบของผู้ใช้ การอัปเดตข้อมูล และการดำเนินการแบบอะซิงโครนัส
การอัปเดต UI ที่คาดเดาได้: ด้วยการแสดงสถานะ UI อย่างชัดเจนในโมเดลและแสดงผลในมุมมอง MVI จึงให้การแยกที่ชัดเจนระหว่างการอัปเดต UI และตรรกะทางธุรกิจ การแยกนี้นำไปสู่การอัปเดต UI ที่คาดเดาได้และสอดคล้องกันมากขึ้น เนื่องจากมุมมองจะแสดงสถานะปัจจุบันเสมอ
การดีบักที่ได้รับการปรับปรุง: ด้วยโฟลว์ทิศทางเดียวและการแสดงสถานะอย่างชัดเจน MVI ช่วยลดความยุ่งยากในการดีบักเนื่องจากมีการติดตามเหตุการณ์และการเปลี่ยนแปลงสถานะที่ชัดเจน ระบุแหล่งที่มาของข้อบกพร่องและติดตามการไหลของข้อมูลผ่านแอปพลิเคชันได้ง่ายขึ้น

แม้ว่า MVI (Model-View-Intent) เป็นรูปแบบสถาปัตยกรรมที่มีประสิทธิภาพในการพัฒนา Android แต่ก็มีข้อผิดพลาดที่อาจเกิดขึ้นซึ่งนักพัฒนาซอฟต์แวร์ควรทราบ ต่อไปนี้เป็นข้อผิดพลาดบางประการของ MVI:

ความซับซ้อนและเส้นโค้งแห่งการเรียนรู้:การใช้ MVI อาจทำให้เกิดความซับซ้อนเพิ่มขึ้นเมื่อเทียบกับรูปแบบที่ง่ายกว่า เช่น MVC หรือ MVP กระแสข้อมูลทิศทางเดียวและแนวคิดการเขียนโปรแกรมเชิงโต้ตอบอาจมีช่วงการเรียนรู้ที่สูงชันกว่า โดยเฉพาะอย่างยิ่งสำหรับนักพัฒนาที่ยังใหม่กับแนวคิดเหล่านี้ อาจต้องใช้เวลาสักระยะเพื่อทำความเข้าใจและนำแนวคิดเหล่านี้ไปปฏิบัติอย่างเหมาะสม
Boilerplate Code: MVI มักจะต้องเขียนโค้ดสำเร็จรูปจำนวนมาก เช่น การกำหนดคลาส Intent แยกต่างหาก แบบจำลองสถานะ และตัวลดสถานะ โค้ดเพิ่มเติมนี้สามารถนำไปสู่โค้ดเบสที่ใหญ่ขึ้น ซึ่งอาจส่งผลต่อความสามารถในการอ่านโค้ดและการบำรุงรักษา สิ่งสำคัญคือต้องรักษาสมดุลระหว่างการรักษาประโยชน์ของรูปแบบและการรักษาโค้ดเบสให้จัดการได้
การใช้ Reactive Streams มากเกินไป: MVI เข้ากันได้ดีกับหลักการเขียนโปรแกรมเชิงโต้ตอบและไลบรารี่ ซึ่งมักจะใช้เพื่อจัดการการไหลของข้อมูลทิศทางเดียว อย่างไรก็ตาม สิ่งสำคัญคือต้องใช้รีแอคทีฟสตรีมอย่างรอบคอบและไม่ใช้กรณีการใช้งานง่ายๆ ที่ซับซ้อนเกินไป การใช้รีแอคทีฟสตรีมมากเกินไปหรือเพิ่มความซับซ้อนที่ไม่จำเป็นอาจทำให้โค้ดเข้าใจยากขึ้นและความสามารถในการบำรุงรักษาโค้ดลดลง
เส้นโค้งการเรียนรู้สำหรับสมาชิกในทีม:การแนะนำ MVI ให้กับทีมหรือโครงการกับนักพัฒนาที่ไม่คุ้นเคยกับรูปแบบหรือการเขียนโปรแกรมเชิงโต้ตอบอาจเป็นเรื่องที่ท้าทาย สมาชิกในทีมจำเป็นต้องเข้าใจแนวคิดหลักและแนวปฏิบัติที่ดีที่สุดที่เกี่ยวข้องกับ MVI การฝึกอบรม เอกสารประกอบ และการแบ่งปันความรู้ที่เพียงพอสามารถช่วยบรรเทาข้อผิดพลาดนี้ได้
ค่าใช้จ่ายด้านประสิทธิภาพ:การไหลของข้อมูลทิศทางเดียวใน MVI สามารถแนะนำค่าใช้จ่ายด้านประสิทธิภาพบางอย่าง โดยเฉพาะอย่างยิ่งในกรณีที่สถานะมีขนาดใหญ่หรือซับซ้อน การเปลี่ยนแปลงไม่ได้และการสร้างอินสแตนซ์ใหม่ของรัฐในการอัพเดทแต่ละครั้งอาจส่งผลให้มีการใช้งานหน่วยความจำเพิ่มขึ้นและอาจส่งผลกระทบต่อประสิทธิภาพการทำงาน ควรพิจารณาอย่างรอบคอบเพื่อเพิ่มประสิทธิภาพส่วนที่สำคัญต่อประสิทธิภาพของแอปพลิเคชัน
ความซับซ้อนของการดีบัก:แม้ว่า MVI จะแสดงร่องรอยของเหตุการณ์และการเปลี่ยนแปลงสถานะที่ชัดเจน แต่การดีบักแอปพลิเคชัน MVI ที่ซับซ้อนยังคงเป็นเรื่องที่ท้าทาย การไหลของข้อมูลทิศทางเดียวและการแยกข้อกังวลอาจทำให้ยากขึ้นในการระบุแหล่งที่มาของปัญหา โดยเฉพาะอย่างยิ่งในโค้ดเบสที่ใหญ่กว่า ควรใช้เทคนิคการบันทึกและการดีบักที่เหมาะสมเพื่อช่วยในการแก้ไขปัญหา

กำหนดโมเดล:สร้างคลาสข้อมูลหรือคลาสที่ปิดสนิทซึ่งแสดงถึงสถานะของแอปพลิเคชัน ชั้นนี้เก็บข้อมูลที่จำเป็นทั้งหมดสำหรับ UI

data class CounterState(val count: Int)

class CounterActivity : AppCompatActivity() {
    private lateinit var viewModel: CounterViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_counter)
        
        viewModel = ViewModelProvider(this).get(CounterViewModel::class.java)
        
        // Capture user interactions and send Intents to the ViewModel
        incrementButton.setOnClickListener {
            viewModel.processIntent(CounterIntent.Increment)
        }
        
        decrementButton.setOnClickListener {
            viewModel.processIntent(CounterIntent.Decrement)
        }
        
        // Observe the state changes from the ViewModel and update the UI
        viewModel.state.observe(this, Observer { state ->
            state?.let {
                countTextView.text = state.count.toString()
            }
        })
    }
}

class CounterViewModel : ViewModel() {
    private val _state: MutableLiveData<CounterState> = MutableLiveData()
    val state: LiveData<CounterState> get() = _state

    fun processIntent(intent: CounterIntent) {
        val currentState = _state.value ?: CounterState(0)
        val newState = when (intent) {
            is CounterIntent.Increment -> currentState.copy(count = currentState.count + 1)
            is CounterIntent.Decrement -> currentState.copy(count = currentState.count - 1)
        }
        _state.value = newState
    }
}

sealed class CounterIntent {
    object Increment : CounterIntent()
    object Decrement : CounterIntent()
}

แค่นั้นแหละ! คุณใช้รูปแบบ MVI พื้นฐานในโครงการ Android ของคุณโดยใช้ Kotlin View จับการโต้ตอบของผู้ใช้และส่ง Intents ไปยัง ViewModel ซึ่งจะอัปเดตสถานะและแจ้งให้ View อัปเดต UI การไหลแบบทิศทางเดียวช่วยให้มั่นใจได้ถึงวิธีการที่คาดเดาได้และตอบสนองในการจัดการการอัปเดต UI และการโต้ตอบกับผู้ใช้

โดยสรุป รูปแบบสถาปัตยกรรมแต่ละรูปแบบ ได้แก่ MVVM, MVC, MVP และ MVI นำเสนอข้อดีและข้อควรพิจารณาสำหรับการพัฒนา Android การเลือกรูปแบบที่จะใช้ขึ้นอยู่กับข้อกำหนดและเป้าหมายเฉพาะของโครงการของคุณ

MVVM ที่มีการแยกข้อกังวลอย่างชัดเจน การเชื่อมโยงข้อมูลแบบสองทาง และการเขียนโปรแกรมเชิงโต้ตอบ มอบแนวทางที่แข็งแกร่งและบำรุงรักษาได้สำหรับการสร้าง UI ที่ซับซ้อนโดยเน้นที่ความสามารถในการทดสอบและความสามารถในการปรับขนาด

MVC ซึ่งเป็นรูปแบบดั้งเดิม นำเสนอความเรียบง่ายและเข้าใจง่าย ทำให้เหมาะสำหรับโครงการขนาดเล็กหรือเมื่อไม่เน้นการแยกข้อกังวล

MVP ซึ่งเป็นวิวัฒนาการของ MVC แนะนำการแยกระหว่าง View และตรรกะทางธุรกิจ ทำให้ง่ายต่อการทดสอบและบำรุงรักษา codebase เป็นตัวเลือกที่ดีเมื่อคุณต้องการมุ่งเน้นไปที่ความสามารถในการทดสอบและความสามารถในการปรับตัว

MVI ซึ่งมีการไหลของข้อมูลแบบทิศทางเดียวและเน้นที่การเปลี่ยนแปลงไม่ได้ มอบวิธีการที่คาดเดาได้และปรับขนาดได้สูงในการจัดการสถานะ UI และการโต้ตอบของผู้ใช้ เหมาะกับโครงการที่ต้องการการควบคุมและคาดการณ์ในระดับสูงเหนือการจัดการของรัฐ

ท้ายที่สุดแล้ว ทางเลือกที่ถูกต้องของรูปแบบสถาปัตยกรรมจะขึ้นอยู่กับขนาดโครงการของคุณ ความซับซ้อน ความเชี่ยวชาญของทีม และข้อกำหนดเฉพาะ สิ่งสำคัญคือต้องพิจารณาปัจจัยต่างๆ เช่น ความสามารถในการบำรุงรักษา ความสามารถในการทดสอบ การใช้ซ้ำ และช่วงการเรียนรู้สำหรับสมาชิกในทีม

เมื่อเข้าใจจุดแข็งและข้อผิดพลาดของแต่ละรูปแบบ คุณจะสามารถตัดสินใจอย่างรอบรู้และเลือกสถาปัตยกรรมที่สอดคล้องกับเป้าหมายโครงการของคุณได้ดีที่สุด ช่วยให้การพัฒนามีประสิทธิภาพและประสบความสำเร็จในระยะยาว

ขอขอบคุณที่สละเวลาอ่านบทความในบล็อกนี้ ความสนใจและการสนับสนุนของคุณมีความหมายมากสำหรับฉันในฐานะผู้เขียน

หากคุณมีคำถาม ข้อเสนอแนะ หรือข้อเสนอแนะ โปรดอย่าลังเลที่จะติดต่อเรา ฉันยินดีที่จะรับฟังจากคุณและมีส่วนร่วมในการอภิปรายเพิ่มเติม