Miks paljud arendajad keelduvad MVP arhitektuurist?

• Boiilerpliiit. Palju koodi View ja Presenter vahelise sideme jaoks: View liidesed, Presenter'i rakendamine, elutsükli haldus.
• Presenter'i testimise keerukus. Tihti on vaja mockida View, mis võib ise olla keeruline ja sõltuvustega.
• Seisundi säilitamise probleemid. Konfiguratsiooni muutmisel (näiteks ekraani pööramisel) tuleb käsitsi säilitada ja taastada Presenter'i seisund, mis võib olla tülikas.
• Halb skaleeritavus. Ekraani keerukuse suurenedes võib Presenter muutuda raskeks ja hooldatavaks.
• Otsese ühenduse puudumine View ja andmete vahel. View ei pääse otse andmetele ligi, kõik päringud läbib Presenter, mis võib lihtsaid toiminguid keerulisemaks muuta.

Näide koodist, mis näitab MVP boilerpliiiti:

// View liides
interface MyView {
    fun showData(data: List<String>)
    fun showError(message: String)
}

// Presenter liides
interface MyPresenter {
    fun attachView(view: MyView)
    fun detachView()
    fun loadData()
}

// Presenter'i rakendus
class MyPresenterImpl(private val model: MyModel) : MyPresenter {

    private var view: MyView? = null

    override fun attachView(view: MyView) {
        this.view = view
    }

    override fun detachView() {
        view = null
    }

    override fun loadData() {
        // Andmete laadimine
        val data = model.getData()
        view?.showData(data)
    }
}

// Näide kasutamisest Activitys
class MyActivity : AppCompatActivity(), MyView {

    private lateinit var presenter: MyPresenter

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

        presenter = MyPresenterImpl(MyModel())
        presenter.attachView(this)
        presenter.loadData()
    }

    override fun onDestroy() {
        super.onDestroy()
        presenter.detachView()
    }

    override fun showData(data: List<String>) {
        // UI uuendamine
    }

    override fun showError(message: String) {
        // Vea näitamine
    }
}