Middle
Prečo mnohí vývojári odmietajú architektúru MVP?
sobes.tech AI
Odpoveď od AI
- Boilerplate. Veľa kódu na prepojenie View a Presenter: rozhrania pre View, implementácia Presenter, správca životného cyklu.
- Problémy s testovaním Presenter. Na testovanie Presenter je často potrebné vytvoriť mock View, ktorá môže byť zložitá a mať závislosti.
- Problémy s uchovávaním stavu. Pri zmene konfigurácie (napríklad otočení obrazovky) je potrebné manuálne uložiť a obnoviť stav Presenter, čo môže byť zdĺhavé.
- Zlá škálovateľnosť. S rastúcou zložitosťou obrazovky sa môže Presenter stať ťažkým a ťažko udržiavateľným.
- Chýbajúca priama väzba medzi View a dátami. View nemá priamy prístup k dátam, všetky požiadavky prechádzajú cez Presenter, čo môže sťažiť jednoduché operácie.
Príklad kódu, ktorý demonštruje boilerplate v MVP:
// Rozhranie View
interface MyView {
fun showData(data: List<String>)
fun showError(message: String)
}
// Rozhranie Presenter
interface MyPresenter {
fun attachView(view: MyView)
fun detachView()
fun loadData()
}
// Implementácia Presenter
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() {
// Simulácia načítania dát
val data = model.getData()
view?.showData(data)
}
}
// Použitie v Activity
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>) {
// Aktualizácia UI
}
override fun showError(message: String) {
// Zobrazenie chyby
}
}