MVC: สาระสำคัญของรูปแบบ Model-View-Controller และการนำไปใช้งาน

MVC คืออะไร: สาระสำคัญของรูปแบบ Model-View-Controller

MVC (Model-View-Controller) เป็นรูปแบบสถาปัตยกรรมที่เสนอโดย Trygve Reenskaug ในปี 1979 สำหรับภาษา Smalltalk-80 รูปแบบนี้แบ่งแอปพลิเคชันออกเป็นสามชั้น: Model ประกอบด้วยข้อมูลและตรรกะทางธุรกิจ View รับผิดชอบการแสดงผล Controller ประมวลผลอินพุตของผู้ใช้และอัปเดต Model และ View การแยกความรับผิดชอบช่วยให้สามารถเปลี่ยนแปลงแต่ละชั้นได้อย่างอิสระ — ตัวอย่างเช่น การเปลี่ยน View จาก UIKit เป็น SwiftUI โดยไม่เปลี่ยนแปลงตรรกะทางธุรกิจใน Model

การโต้ตอบของส่วนประกอบ ใน MVC เป็นไปตามวงจร: ผู้ใช้โต้ตอบกับ View → Controller รับเหตุการณ์ → Controller อัปเดต Model → Model แจ้ง Controller ถึงการเปลี่ยนแปลง → Controller อัปเดต View ในการนำไปใช้แบบคลาสสิก Model ใช้รูปแบบ Observer: เมื่อข้อมูลเปลี่ยนแปลง Model จะส่งการแจ้งเตือน Controller จะสมัครรับและอัปเดต View ในการนำไปใช้ของ Apple, Key-Value Observing (KVO) หรือ NotificationCenter ทำหน้าที่นี้

MVC ในการพัฒนามือถือสมัยใหม่ ถูกใช้น้อยกว่าเมื่อ 10 ปีก่อน แต่ยังคงจำเป็นต้องเข้าใจ Apple แนะนำ MVC สำหรับหน้าจอที่เรียบง่ายในแอปพลิเคชัน UIKit Google ไม่แนะนำ MVC บริสุทธิ์สำหรับ Android — เอกสารทางการแนะนำ MVVM กับ Jetpack อย่างไรก็ตาม ความรู้เกี่ยวกับ MVC เป็นสิ่งจำเป็นสำหรับการทำงานกับโปรเจ็กต์เดิมและการทำความเข้าใจวิวัฒนาการของรูปแบบสถาปัตยกรรม

MVC ใน iOS: UIViewController และ Storyboard

Apple MVC เป็นการนำรูปแบบไปใช้แบบกำหนดเองที่สร้างไว้ใน UIKit UIViewController ทำหน้าที่เป็น Controller: จัดการวงจรชีวิตของหน้าจอ (viewDidLoad, viewWillAppear, viewDidDisappear), จัดการการสัมผัสและการกระทำของผู้ใช้, อัปเดต View ผ่าน IBOutlets View ถูกสร้างใน Interface Builder (storyboard หรือ XIB) หรือโดยโปรแกรม Model — ออบเจ็กต์ข้อมูลใดๆ: บริการเครือข่าย, สแต็ก CoreData, โครงสร้าง Swift

final class UserViewController: UIViewController {
    // View (ผ่าน storyboard outlet)
    @IBOutlet private var nameLabel: UILabel!
    @IBOutlet private var emailLabel: UILabel!

    // Model
    private let userService = UserService()

    override func viewDidLoad() {
        super.viewDidLoad()
        loadUser()
    }

    private func loadUser() {
        userService.fetchUser { [weak self] user in
            // Controller อัปเดต View
            self?.nameLabel.text = user.name
            self?.emailLabel.text = user.email
        }
    }
}

ปัญหาของ Apple MVC — View และ Controller ถูกเชื่อมโยงอย่างแน่นหนา UIViewController จัดการทั้ง View และตรรกะพร้อมกัน Storyboard เก็บ View ใน XML แต่ตัวควบคุมมีการอ้างอิงโดยตรงไปยังองค์ประกอบ UI ผ่าน IBOutlets สิ่งนี้ละเมิดหลักการความรับผิดชอบเดียว: ตัวควบคุมรับผิดชอบวงจรชีวิต, ตัวแทน, แหล่งข้อมูล, target-action และแอนิเมชัน ผลลัพธ์คือ หน้าจอแอป iOS มาตรฐานมี 200–500 บรรทัดในตัวควบคุม

วงจรชีวิตของ ViewController — Apple มี 6 เมธอดวงจรชีวิต: loadView (การสร้าง View ด้วยตนเอง), viewDidLoad (หลังจากโหลด View ในหน่วยความจำ), viewWillAppear (ก่อนปรากฏบนหน้าจอ), viewDidAppear (หลังจากแอนิเมชัน), viewWillDisappear (ก่อนออกจากหน้าจอ), viewDidDisappear (หลังจากออก) แต่ละเมธอดเป็นสถานที่สำหรับวางตรรกะใน MVC การใช้เมธอดเหล่านี้สำหรับตรรกะทางธุรกิจจะเร่งการขยายตัวของตัวควบคุม

MVC ใน Android: Activity, Fragment และ XML Layout

Android MVC — Activity และ Fragment ทำหน้าที่เป็น Controller ไฟล์ XML layout เป็น View คลาส POJO ใดๆ ที่มีข้อมูลเป็น Model Activity จัดการวงจรชีวิตของหน้าจอ: onCreate, onStart, onResume, onPause, onStop, onDestroy Fragment เป็นหน้าจอย่อยภายใน Activity ที่มีวงจรชีวิตของตัวเอง View (XML) แยกจาก Controller และโหลดผ่าน setContentView หรือ LayoutInflater Model — พื้นที่จัดเก็บ, ฐานข้อมูล, การเรียกเครือข่าย

class UserActivity : AppCompatActivity() {
    // View ผ่าน XML layout
    private lateinit var binding: ActivityUserBinding

    // Model
    private val userRepository = UserRepository()

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

    private fun loadUser() {
        userRepository.getUser { user ->
            runOnUiThread {
                binding.nameText.text = user.name
                binding.emailText.text = user.email
            }
        }
    }
}

Android ViewBinding และ DataBinding — เครื่องมือที่ทันสมัยที่ลดการเชื่อมโยงระหว่าง Controller และ View ViewBinding สร้างคลาสที่มีการอ้างอิงโดยตรงไปยัง Views จาก XML ทำให้ findViewById ไม่จำเป็น DataBinding เพิ่มความสามารถในการผูกข้อมูลกับ UI ในมาร์กอัป XML ผ่าน @{user.name} DataBinding เป็นก้าวไปสู่ MVVM เพราะช่วยให้ส่งข้อมูลจาก Model ไปยัง View โดยไม่มีโค้ดใน Activity Google แนะนำ DataBinding สำหรับโปรเจ็กต์ใหม่ทั้งหมด

วงจรชีวิต Android ซับซ้อนกว่า iOS: Activity สามารถถูกทำลายและสร้างใหม่เมื่อหมุนหน้าจอ หน่วยความจำไม่เพียงพอ หรือการเปลี่ยนแปลงการกำหนดค่า ใน MVC บริสุทธิ์ ตัวควบคุม (Activity) มีตรรกะที่สูญเสียไปเมื่อถูกทำลาย ซึ่งจำเป็นต้องบันทึกสถานะผ่าน onSaveInstanceState หรือ ViewModel จาก Jetpack ซึ่งเกินขอบเขตของ MVC บริสุทธิ์และทำให้สถาปัตยกรรมใกล้เคียงกับ MVVM มากขึ้น

Massive View Controller และข้อจำกัดของ MVC

Massive View Controller เป็นคำที่อธิบายปัญหาหลักของ MVC ในการพัฒนามือถือ ตัวควบคุมใน iOS และ Android รับผิดชอบมากเกินไป: การประมวลผลอินพุต, การตรวจสอบข้อมูล, การโต้ตอบเครือข่าย, การนำทาง, การแคช, แอนิเมชัน, การจัดการวงจรชีวิต ผลลัพธ์คือ ตัวควบคุมขยายใหญ่เป็น 500–2000 บรรทัดของโค้ด อ่าน ทดสอบ และบำรุงรักษาได้ยาก

สาเหตุของ Massive View Controller — สถาปัตยกรรมของ UIKit และ Android Framework สนับสนุนการวางตรรกะในตัวควบคุม การเรียกเครือข่าย, การประมวลผล JSON, การนำทาง — ทั้งหมดนี้ไปอยู่ใน Activity หรือ UIViewController โดยธรรมชาติเพราะสามารถเข้าถึงวงจรชีวิตและ UI ได้ นักพัฒนาต้องแยกตรรกะออกไปยังคลาสแยกต่างหาก (Service, Manager, Interactor) อย่างมีสติ ซึ่งต้องมีวินัยและความเข้าใจในหลักการสถาปัตยกรรม

การทดสอบ MVC — Model ถูกทดสอบแยกด้วยการทดสอบหน่วย Controller ทดสอบยากเนื่องจากการพึ่งพา UIKit/UIFoundation XCTest ไม่อนุญาตให้สร้าง UIViewController โดยไม่มีหน้าต่างดู สำหรับ Android, ActivityTestRule และ Robolectric แก้ปัญหาได้บางส่วน แต่การทดสอบช้า View มักไม่ถูกทดสอบด้วยการทดสอบหน่วย — สำหรับ UI จะใช้การทดสอบภาพหน้าจอและการทดสอบ UI (XCUITest, Espresso)

เมื่อใด MVC จึงเหมาะสม — หน้าจอเรียบง่ายที่มีหนึ่งหรือสององค์ประกอบ (หน้าจอเข้าสู่ระบบ, โปรไฟล์, การตั้งค่า) ต้นแบบและ MVP สำหรับการตรวจสอบสมมติฐาน — MVC เขียนได้เร็วกว่าโดยไม่มีชั้นเพิ่มเติม โปรเจ็กต์ที่มีฐานโค้ดขนาดเล็กถึง 10–15 หน้าจอ ในโปรเจ็กต์ที่ซับซ้อน MVC นำไปสู่การสะสมหนี้ทางเทคนิคและต้องการการปรับโครงสร้างทุก 6–12 เดือน

การเปรียบเทียบ MVC กับ MVVM, MVP และ Clean Architecture

MVC vs MVVM — ความแตกต่างหลัก: ใน MVVM ตัวควบคุมถูกแทนที่ด้วย ViewModel ที่ไม่มีการอ้างอิงถึง View ข้อมูลถูกส่งผ่าน Observable (SwiftUI), LiveData/StateFlow (Android) หรือ Combine/RxSwift ViewModel สามารถทดสอบได้ด้วยการทดสอบหน่วยโดยไม่ต้องพึ่งพา UI Apple แนะนำ MVVM กับ SwiftUI ตั้งแต่ปี 2019, Google — MVVM กับ LiveData/Flow เป็นสถาปัตยกรรม Android อย่างเป็นทางการ MVVM ต้องใช้โค้ดมากขึ้นสำหรับการผูก แต่ปรับปรุงความสามารถในการทดสอบอย่างมาก

MVC vs MVP — ใน MVP (Model-View-Presenter) Presenter เป็นชั้นที่ทดสอบได้ซึ่งรับ View ผ่านอินเทอร์เฟซ แตกต่างจาก MVC ที่ Controller จัดการ View โดยตรงผ่าน UIKit Presenter ไม่ได้ขึ้นอยู่กับเฟรมเวิร์ก — มันทำงานผ่านนามธรรม ViewInterface MVP ได้รับความนิยมในการพัฒนา Android ก่อน Jetpack และใช้ในโปรเจ็กต์เดิม Presenter มีอายุยืนกว่า Activity และรักษาสถานะเมื่อหมุนหน้าจอ

MVC vs Clean Architecture — Clean Architecture เพิ่มชั้น: Use Cases (Interactors), Entities, Gateways และ Repository MVC ยังคงอยู่ในชั้น Presentation แต่ตรรกะทางธุรกิจถูกย้ายไปยังชั้น Domain พร้อม Use Cases Clean Architecture แก้ปัญหา Massive View Controller อย่างรุนแรง — Controller มีเพียงการเรียก Use Cases และการอัปเดต View ข้อเสียคือจำนวนคลาสและไฟล์เพิ่มขึ้นอย่างมาก ซึ่งสมเหตุสมผลสำหรับโปรเจ็กต์ที่มี 50+ หน้าจอ

// MVC ใน iOS: Controller มีทุกอย่าง
class OrderViewController: UIViewController {
    func placeOrder() {
        // การตรวจสอบ + เครือข่าย + การอัปเดต UI
        guard Validation.isValid(total) else { return }
        NetworkService.shared.submit(order) { [weak self] result in
            self?.handleResult(result)
        }
    }
}

// MVVM: ตรรกะใน ViewModel
class OrderViewModel: ObservableObject {
    @Published var state: OrderState = .idle
    func placeOrder() { /* ตรรกะทางธุรกิจ */ }
}

การเลือกสถาปัตยกรรม ขึ้นอยู่กับขนาดทีม ขอบเขตโปรเจ็กต์ และความสามารถในการทดสอบที่ต้องการ สำหรับทีมที่มีนักพัฒนา 1–2 คนและโปรเจ็กต์สูงสุด 20 หน้าจอ MVVM ทำงานได้ดี สำหรับทีมใหญ่ที่มีนักพัฒนา 5+ คนและโปรเจ็กต์ที่มี 50+ หน้าจอ — Clean Architecture ที่มีโครงสร้างแบบโมดูลาร์ MVC ยังคงมีความเกี่ยวข้อง สำหรับการทำความเข้าใจวิวัฒนาการของสถาปัตยกรรม การบำรุงรักษาโปรเจ็กต์เดิม และสำหรับหน้าจอ UIKit ง่ายๆ ที่ไม่มีตรรกะทางธุรกิจที่ซับซ้อน