Xin chào các công dân mới toanh vừa gia nhập thế giới kiến trúc ứng dụng. Tính bài trước, các bạn đã là bước chân vào thế giới này rồi. Hôm nay với vai trò là một công dân "già", mình sẽ giới thiệu các bạn đến một số "địa điểm" nổi tiếng nhất của thế giới này:
- MVC: View - Controller - Model
- MVP: View - Presenter - Model
- MVVM: View - View Model - Model
- VIPER: View - Presenter (with Router/Wireframe) - Interactor - Entity (Model)
Điểm chung đó chính là View và Model luôn ở đầu và cuối và có xu hướng rời xa nhau.
Mối liên kết giữa View - Model trong kiến trúc ứng dụng
Ta đang nói về kiến trúc ứng dụng, nghĩa là thiết kế kiến trúc cho ứng dụng. Ứng dụng thì sẽ luôn có giao diện người dùng (graphic user interface - GUI) và phần code cũng như dữ liệu (data - model) để phục vụ cho giao diện trên (hay còn gọi là View). Thông thường View không chỉ hiển thị dữ liệu mà còn nhận vào tác tương tác của người dùng để thao tác trên dữ liệu, còn dữ liệu thì cũng không đơn giản là muốn show là show được, đôi khi phải thông qua các formatter, converter cũng như các service cung cấp bên ngoài như các Restful API.Sự tồn tại của View - Model là bắt buộc. Chúng ta đã biết, một class không thể có quá nhiều logic trong nó và khi có 2 class trở lên có quan hệ với nhau thì ta phải tìm cách để chúng giảm lệ thuộc vào nhau. Đây là vấn đề đã làm đau đầu các kiến trúc sư trong nửa thế kỷ qua. Theo tốc độ phát triển của nền công nghiệp lập trình ứng dụng, có rất nhiều các mô hình ra đời để giải quyết bài toán trên. Và khi cơn đau đầu của họ đã qua thì tới cơn đau đầu của chúng ta, nên chọn mô hình nào để áp ụng bây giờ ?!
Khi mới học làm ứng dụng (trong bài này mình viết app cho iOS), chúng ta thường chỉ muốn tìm hiểu các thành phần cần thiết để làm được app và tập trung vào lập trình tính năng. Những app ban đầu ta làm vì quá đơn giản nên phần kiến trúc app sẽ thường bị loại bỏ để ta có thể focus đúng vào cái ta cần. Đến khi ta đã biết lập trình app rồi thì bước tiếp theo đó là làm thế nào để có thể làm được những app đạt chất lượng tốt về cả hiệu năng lẫn khả năng dễ bảo trì, dễ test và phát triển. Mình tin đó là lý do tại sao các bạn đã đọc đến bài này.
Trong phần còn lại của bài viết, mình sẽ làm một app cực kỳ đơn giản và áp dụng lần lượt tất cả các mô hình MVC, MVP, MVVM và VIPER vào để các bạn dễ hiểu và dễ so sách từ đó sẽ dễ dàng lựa chọn mô hình phù hợp cho ứng dụng và team. Qua đó mình hy vọng sẽ giúp các bạn "đỡ đau" phần nào.
Ứng dụng ta cần viết sẽ như sau:
MVC
Source code phiên bản cho người mới học chỉ có nhiu đây thôi (phần giao diện mình làm với Storyboard):import UIKit
class NumberVC: UIViewController {
@IBOutlet weak var numberLabel: UILabel!
@IBOutlet weak var decreaseButton: UIButton!
var number:Int = 0
override func viewDidLoad() {
super.viewDidLoad()
self.initDataAndShow()
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
func initDataAndShow() {
number = 3
self.numberLabel.text = "\(number)"
}
@IBAction func decreaseAction(_ sender: UIButton) {
number -= 1
self.numberLabel.text = "\(number)"
if number == 0 {
self.decreaseButton.isEnabled = false
}
}
@IBAction func increaseAction(_ sender: UIButton) {
number += 1
self.decreaseButton.isEnabled = true
self.numberLabel.text = "\(number)"
}
}Tuy nhiên trong đoạn code trên không hề có Model mà chỉ dùng một biến số nguyên number. Mặt khác ta cũng thấy rằng có khá nhiều dòng code lặp lại
self.numberLabel.text = "\(number)". Để làm đúng và tốt hơn mình sẽ đổi lại như sau:// File NumberModel.swift
import Foundation
class NumberModel {
private var value:Int = 0
init(value:Int) {
self.value = value
}
func getValue() -> Int {
return self.value
}
func setValue(value:Int) {
self.value = value
}
}
// File NumberVC.swift
import UIKit
class NumberVC: UIViewController {
@IBOutlet weak var numberLabel: UILabel!
@IBOutlet weak var decreaseButton: UIButton!
var number:NumberModel!
override func viewDidLoad() {
super.viewDidLoad()
self.initDataWith(val: 3)
self.updateUI()
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
func initDataWith(val:Int) {
self.number = NumberModel(value: val)
}
func updateUI() {
self.numberLabel.text = "\(number.getValue())"
self.decreaseButton.isEnabled = number.getValue() > 0
}
@IBAction func decreaseAction(_ sender: UIButton) {
self.number.setValue(value: self.number.getValue() - 1)
self.updateUI()
}
@IBAction func increaseAction(_ sender: UIButton) {
self.number.setValue(value: self.number.getValue() + 1)
self.updateUI()
}
}func updateUI() {
self.numberLabel.text = String(format: "%02d", arguments: [number.getValue()])
self.decreaseButton.isEnabled = number.getValue() > 0
}Mô hình MVC dù đã hoàn thành nhiệm vụ phân tách được View - Model tuy nhiên cũng còn những điểm yếu như:
- Logic của Controller dễ phình to (trở thành massive controller) do tương lai phải quản lý cả logic của View như: animation, show các popup nếu có, bặt tắt các control tương ứng, ... và logic để thao tác với data => khó bảo trì và mở rộng.
- Vì các phương thức của controller phải làm việc với cả View và Model nên sẽ gây khó khăn khi tạo các lớp mock cho Unit Test => Khó test
MVP
Trong mô hình MVP sẽ có một số đặc điểm sau:
- Model: cũng giống như mô hình MVC.
- View: View cũng tương tự MVC tuy nhiên ta sẽ sử dụng trừu tượng để giảm lệ thuộc giữa View và Presenter. View do đặc điểm sẽ nhận kết quả từ Presenter một cách bị động, nên thường được gọi là Passive View hay Dumb View.
- Presenter: đây là lớp thay thế cho Controller, nhiệm vụ của nó là xử lý các thao tác của user trên view rồi làm việc với Model rồi gởi kết quả về View.
- User sẽ thao thác trên View thay vì là Controller. Do class ViewController (View + Controller) khá đặc biệt nên ta không thấy rõ điều này. Nhưng nếu là trên lập trình Winform thì sẽ rõ ràng hơn.
- Mối liên kết giữa View và Presenter là 1 - 1
Đầu tiên là protocol của phần trừu tượng của View. Trên thực tế View này chỉ cần nhận về 2 thứ: giá trị của number hiện tại dưới dạng String (đã format) và nút giảm số có được enabled hay không.
import Foundation
protocol NumberView:class {
func setTextNumber(text:String)
func updateDecreaseControl(enabled:Bool)
}Presenter sẽ giữ một kết nối yếu (weak) về View chể chống retain cycle, đây là protocol chứ không phải là instance cụ thể. Sau khi thao tác tăng giảm number trên Model, presenter sẽ gởi kết quả về View.
import Foundation
class NumberPresenter {
private var numberModel:NumberModel?
private weak var numberView:NumberView?
init(model:NumberModel) {
self.numberModel = model
}
func attach(view:NumberView) {
self.numberView = view
updateView()
}
func increaseNumber() {
guard let numberModel = self.numberModel else { return }
numberModel.setValue(value: numberModel.getValue() + 1)
self.updateView()
}
func decreaseNumber() {
guard let numberModel = self.numberModel else { return }
let currentValue = numberModel.getValue()
if currentValue <= 0 { return }
numberModel.setValue(value: currentValue - 1)
self.updateView()
}
private func updateView() {
guard let numberModel = self.numberModel,
let numberView = self.numberView
else { return }
let text = String(format: "%02d", arguments: [numberModel.getValue()])
numberView.setTextNumber(text: text)
numberView.updateDecreaseControl(enabled: numberModel.getValue() > 0)
}
}NumberVC đóng vai trò là View vì thế sẽ phải adopt protocol NumberView. Trong lifecycle method viewDidLoad ta cho attach View vào Presenter để View bắt đầu nhận kết quả khởi tạo từ Presenter (trên thực tế có thể là những Service lấy data từ các API).
import UIKit
class NumberVC: UIViewController, NumberView {
@IBOutlet weak var numberLabel: UILabel!
@IBOutlet weak var decreaseButton: UIButton!
private let numberPresenter = NumberPresenter(model: NumberModel(value: 3))
override func viewDidLoad() {
super.viewDidLoad()
self.numberPresenter.attach(view: self)
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
@IBAction func decreaseAction(_ sender: UIButton) {
self.numberPresenter.decreaseNumber()
}
@IBAction func increaseAction(_ sender: UIButton) {
self.numberPresenter.increaseNumber()
}
// Implement methods from NumberView
func setTextNumber(text: String) {
self.numberLabel.text = text
}
func updateDecreaseControl(enabled: Bool) {
self.decreaseButton.isEnabled = enabled
}
}Ưu điểm của mô hình MVP là View bây giờ chỉ còn là 1 phần nhỏ của ViewController. Presenter sẽ không cần biết View là class nào, miễn là có adopt protocol NumberView là được. Việc này giúp ta có thể dễ dàng test được Presenter như sau:
import XCTest
@testable import NumberCounterMVP
class NumberViewMock:NumberView {
var textValue = ""
var descreaseEnabled = true
func setTextNumber(text: String) {
self.textValue = text
}
func updateDecreaseControl(enabled: Bool) {
self.descreaseEnabled = enabled
}
}
class NumberPresenterTests: XCTestCase {
var numberModel:NumberModel!
var numberPresenter:NumberPresenter!
var numberViewMock = NumberViewMock()
override func setUp() {
super.setUp()
self.numberModel = NumberModel(value: 10)
self.numberPresenter = NumberPresenter(model: numberModel)
self.numberPresenter.attach(view: numberViewMock)
}
override func tearDown() {
super.tearDown()
}
func testInitValueMustBeTen() {
XCTAssert(numberViewMock.textValue == "10", "Init number is not \"10\".")
}
func testIncreaseNumber() {
self.numberPresenter.increaseNumber()
XCTAssert(numberViewMock.textValue == "11", "Number is not \"11\" after increased.")
}
func testDecreaseNumber() {
self.numberPresenter.decreaseNumber()
XCTAssert(numberViewMock.textValue == "09", "Number is not \"09\" after decreased.")
}
func testDecreaseDisableWhenNumberIsZero() {
for _ in 1...10 {
self.numberPresenter.decreaseNumber()
}
XCTAssert(numberViewMock.descreaseEnabled == false, "Decrease control still enabled when number is 0.")
}
}
Comments
Post a Comment