Middle
Proč odmítá mnoho vývojářů architekturu MVP?
sobes.tech AI
Odpověď od AI
- Boilerplate. Hodně kódu pro spojení View a Presenter: rozhraní pro View, implementace Presenter, správci životního cyklu.
- Obtížnost testování Presenter. Pro testování Presenter je často nutné mockovat View, která může být složitá a mít závislosti.
- Problémy s uchováváním stavu. Při změně konfigurace (například otočení obrazovky) je nutné ručně ukládat a obnovovat stav Presenter, což může být komplikované.
- Špatná škálovatelnost. S růstem složitosti obrazovky může být Presenter těžký a obtížně udržovatelný.
- Chybějící přímé spojení mezi View a daty. View nemá přímý přístup k datům, všechny požadavky procházejí přes Presenter, což může ztížit jednoduché operace.
Příklad kódu ukazující boilerplate v MVP:
// Rozhraní View
interface MyView {
fun showData(data: List<String>)
fun showError(message: String)
}
// Rozhraní Presenter
interface MyPresenter {
fun attachView(view: MyView)
fun detachView()
fun loadData()
}
// Implementace 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() {
// Simulace načítání dat
val data = model.getData()
view?.showData(data)
}
}
// Příklad použití 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>) {
// Aktualizace UI
}
override fun showError(message: String) {
// Zobrazení chyby
}
}