Die Programmgeschwindigkeit ist es wahrscheinlich nicht, durch die Übergaben der Daten werden zusätzliche Befehle notwendig die die Geschwindigkeit des Programms verringert.
In gewissem Maße zu vernachlässigen - UI Code muss kein Highperformance Code wie auf nem 24/7 Server sein - natürlich sollte man hier keine Verzögerungen haben, dass die UI zäh wird.
Besser Wartbarkeit? Ich weis nicht, wenn eine Datenbank-Anwendung um ein neues Datenbankfeld erweitern werden muss, so muss diese Änderung in allen Modulen berücksichtig werden.
Auf jeden Fall, es geht darum, Zuständigkeiten zu trennen. Natürlich muss ich auch dann noch im Datenmodell, im Presenter/Controller/whatever und in der UI dafür sorgen, dass das neue Feld auch richtig funktioniert. Aber es ist klarer, wo und was ich ändern muss, als wenn alles ein großer Klump ist - und wir reden hier nicht von einfach nen Dataset, DataSource, Grid, fertig Anwendung - da würd ich auch kein MVC/MVP/MVVM praktizieren.
Besser Testen? Man muss die Übergaben der Module zusätzlich testen, dass bedeutet erstmal Mehraufwand.
Hier kommt ein Vorteil beim Einsatz eines Frameworks/Bibliothek zum tragen, das teste ich einmal und weiß, dass es funktioniert. Viele dieser Bibliotheken verfügen auch über Mechanismen zum Protokollieren, so dass man sehen kann, wenn irgendwo eine Verbindung fehlt oder nicht passt. Zudem gibt es noch einen Vorteil wenn man das sogenannte
Convention over Configuration einsetzt (zugegeben, das kann zu Beginn schon arg "magic" sein) - aber es befreit von manuellem Anstöpseln der verschiedenen Teile.
Man kann die
GUI austauschen, wirklich? Entwickelt wurde für einen Destop-PC, jetzt soll das Programm auch auf Mobilgeräte laufen, auch hier kommt man nicht herum in den meisten Modulen eine Anpassung durchzuführen. Man braucht sich ja nur mal Windows 10 ansehen, wie es aussieht, wenn man versucht ein Destop-Programm auch für Mobilgeräte fit zu machen.
Dein Vergleich hinkt. Bei der Entkopplung der Businesslogik von der UI kann ich mir für jede Plattform die UI so basteln, wie ich mag, aber wenn die Geschäftslogik (Validierung, triggern von anderen Komponenten, verbindung zur Datenbank, whatever) nicht direkt an die UI, ihre Events (kurz code behind, aka "onclick programmming") geklöppelt sind, dann kann man die so 1 zu 1 wiederverwenden.
Ich finde das diese Entwurfsmuster auch dazu führen, dass man einfach drauflosentwickelt, man nennt das dann einfach „agil“ und schon ist alles OK.
"Agil" heißt keineswegs einfach drauf los - aber das zu diskutieren, wäre besser in einem eigenen Thread aufgehoben.
Außerdem, für viele Probleme gibt es kein Muster, oder jedenfalls kein bekanntes Muster, entweder weil das Problem zu selten auftritt oder weil es jeweils ganz spezifisch im jeweiligen Kontext neu gelöst werden muss.
Bedingt. Wenn man sich mal näher mit Entwurfsmustern beschäftigt, wird man erstaunt sein, wo man sie überall wiederfindet oder auch "aus Versehen"/ohne es zu wissen selbst eingesetzt hat.
Aber dazu gehört auch zu wissen, wann man etwas anders machen muss, weil...
Dieser Beitrag soll nur zum Nachdenken anregen, weil man sich vor Extreme hüten sollte.
Da stimme ich dir uneingeschränkt zu - aber je mehr Möglichkeiten man kennt, desto besser kann man entscheiden, wie man etwas löst und wo man vom "Standard" abweichen muss.