Middle
Miért utasítják el sok fejlesztő az MVP architektúrát?
sobes.tech MI
Válasz az MI-től
- Boilerplate. Sok kód a View és a Presenter összekapcsolásához: interfészek a View-hez, a Presenter megvalósítása, életciklus kezelők.
- A Presenter tesztelésének nehézségei. A Presenter teszteléséhez gyakran szükség van a View mockolására, ami bonyolult lehet és függőségekkel járhat.
- Állapotmegőrzési problémák. Konfigurációváltozás esetén (pl. képernyőforgatás) manuálisan kell menteni és visszaállítani a Presenter állapotát, ami nehézkes lehet.
- Gyenge skálázhatóság. Ahogy a képernyő komplexitása nő, a Presenter nehézzé és karbantarthatatlanná válhat.
- Közvetlen kapcsolat hiánya a View és az adatok között. A View nem fér hozzá közvetlenül az adatokhoz, minden kérés a Presenter-en keresztül történik, ami megnehezítheti az egyszerű műveleteket.
Példa kód, ami bemutatja a boilerplate-t MVP-ben:
// View interfész
interface MyView {
fun showData(data: List<String>)
fun showError(message: String)
}
// Presenter interfész
interface MyPresenter {
fun attachView(view: MyView)
fun detachView()
fun loadData()
}
// Presenter megvalósítása
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() {
// Adatok betöltésének szimulációja
val data = model.getData()
view?.showData(data)
}
}
// Használat Activity-ben
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 frissítése
}
override fun showError(message: String) {
// Hiba megjelenítése
}
}