MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?)

Alles was sonst Nirgends passt
User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?)

Post by daemotron » 2010-09-11 23:53

Joe User wrote:MVC und strikte Code<->Design-Trennung waren 2003 noch nicht wirklich angesagt wie heute

Auch wenn's OT ist, hier muss ich Dir widersprechen: MVC war schon "damals" state of the art für professionelle Anwendungen, nicht nur im Webbereich. Spring entstand etwa um den Dreh rum, und Struts ist noch mal zwei, drei Jährchen älter.

Joe User wrote:wobei ich MVC als dumme Einbahnstrasse erachte, aber das gehört hier nicht her ;)

Jetzt hast Du mich neugierig gemacht - sollten wir bei Gelegenheit mal drüber diskutieren :ymparty:
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time

danu
Posts: 263
Joined: 2005-02-02 11:15

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by danu » 2010-09-12 08:50

Ja, würde mich auch interessieren. Wie räume ich 500 KB Spaghetti Code auf?

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-12 11:00

Bei MVC muss ich für eine Änderung mindestens drei Baustellen (im Zweifel auch drei Files) beachten und/oder bearbeiten. Bei einfachen Funktionen/Klassen/Macros/etc ohne MVC (gibt es dafür eine Hype-Bezeichnung?) ist es hingegen nur eine Baustelle. Ich habe also schonmal mehr Arbeit, obwohl mir MVC eigentlich Arbeit einsparen sollte. Allein das spricht für mich schon gegen MVC.

Auf Grund dieser drei Baustellen ist es auch schwieriger als ohnehin schon sich in fremden Code einzuarbeiten, da man immer drei Dinge parallel betrachten muss. Das erschwert auch das Bugfixing.

Warum Einbahnstrasse? Weil man zwar recht günstig von "einfachen Strukturen" (siehe oben) zu MVC migrieren kann, aber nur sehr teuer zurück. Für mich ist MVC eben nur ein Hype, ging ja jahrzehntelang auch ohne MVC sehr gut.

PS: Warum nutzen Assembler-Programmierer kein MVC, wenn es so toll ist? ;)
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Roger Wilco » 2010-09-12 12:06

Joe User wrote:Bei einfachen Funktionen/Klassen/Macros/etc ohne MVC (gibt es dafür eine Hype-Bezeichnung?) ist es hingegen nur eine Baustelle.

Wie wuerdest du in deisem Fall z. B. das Feature implementieren, in einer Anwendung verschiedene "Skins"/"Themes" auswaehlen zu koennen?

Joe User wrote:Ich habe also schonmal mehr Arbeit, obwohl mir MVC eigentlich Arbeit einsparen sollte. Allein das spricht für mich schon gegen MVC.

Also die Tatsache, dass du in einem Fall drei Dateien oeffnen musst und im anderen Fall nicht (ist das wirklich der Fall?) ist fuer mich kein hinreichender Grund pro oder contra MVC.

Joe User wrote:Auf Grund dieser drei Baustellen ist es auch schwieriger als ohnehin schon sich in fremden Code einzuarbeiten, da man immer drei Dinge parallel betrachten muss.

Gerade weil das Entwurfsmuster MVC allgemein bekannt ist und die Strukturen dahinter verstanden sind, ist eine Einarbeitung in fremden Code, der sich an die entsprechenden Prinzipien haelt, einfacher.

Joe User wrote:Das erschwert auch das Bugfixing.

Meiner Meinung nach erleichtert die Einhaltung einer strikten Struktur (sei es jetzt MVC, HMVC, MVP oder ein komplett anderes Entwurfsmuster) das Bugfixing, eben weil sich ein Entwickler sofort bzw. mit wenig Einarbeitungszeit zurecht findet und die Zusammenhaenge verstehen kann.

Joe User wrote:Weil man zwar recht günstig von "einfachen Strukturen" (siehe oben) zu MVC migrieren kann, aber nur sehr teuer zurück.

Das haelt sich bei einer hinreichend komplexen Anwendung die Waage. Wir sprechen ja sicherlich nicht vom 08/15 Hello World Programm.

Joe User wrote:Für mich ist MVC eben nur ein Hype, ging ja jahrzehntelang auch ohne MVC sehr gut.

Stimmt, warum gab es nach C eigentlich noch weitere Programmiersprachen? Man konnte ja jahrzehntelang und kann noch immer sehr gut damit entwickeln.

Joe User wrote:PS: Warum nutzen Assembler-Programmierer kein MVC, wenn es so toll ist? ;)

Weil nicht jedes Entwurfsmuster zu jedem Problem passt. Du benutzt ja auch kein Proxy-Pattern, wenn du eigentlich ein Visitor-Pattern willst. Oder ein Factory-Pattern, wenn du eigentlich ein DTO willst.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-12 13:22

@danu
Spaghetti-Code kann ich mit MVC genauso leicht schreiben, wie ohne MVC. Diesen aufzuräumen ist immer eine nervende Arbeit und ein Rewrite manchmal so gar schneller und stressfreier.

@matze
Gutes Beispiel, aber ist das da draussen die Regel? Und wenn ja, was passiert beim nächsten Programmierstilhype? Wird dann wieder Alles über Bord geworfen, damit man wieder State-of-the-art ist und alle Beteiligten müssen wieder umlernen? Wäre mir als Arbeitgeber zu teuer, dann lieber je nach Unternehmensgrösse ein, zwei oder drei qualifizierte Entwickler mehr beschäftigen. Das kommt mich auf lange Sicht günstiger.


Roger Wilco wrote:
Joe User wrote:Bei einfachen Funktionen/Klassen/Macros/etc ohne MVC (gibt es dafür eine Hype-Bezeichnung?) ist es hingegen nur eine Baustelle.

Wie wuerdest du in deisem Fall z. B. das Feature implementieren, in einer Anwendung verschiedene "Skins"/"Themes" auswaehlen zu koennen?

So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Roger Wilco wrote:
Joe User wrote:Ich habe also schonmal mehr Arbeit, obwohl mir MVC eigentlich Arbeit einsparen sollte. Allein das spricht für mich schon gegen MVC.

Also die Tatsache, dass du in einem Fall drei Dateien oeffnen musst und im anderen Fall nicht (ist das wirklich der Fall?) ist fuer mich kein hinreichender Grund pro oder contra MVC.

Es ist nervig und zeitraubend, da helfen auch komfortable IDEs nicht.

Roger Wilco wrote:
Joe User wrote:Auf Grund dieser drei Baustellen ist es auch schwieriger als ohnehin schon sich in fremden Code einzuarbeiten, da man immer drei Dinge parallel betrachten muss.

Gerade weil das Entwurfsmuster MVC allgemein bekannt ist und die Strukturen dahinter verstanden sind, ist eine Einarbeitung in fremden Code, der sich an die entsprechenden Prinzipien haelt, einfacher.

Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Roger Wilco wrote:
Joe User wrote:Das erschwert auch das Bugfixing.

Meiner Meinung nach erleichtert die Einhaltung einer strikten Struktur (sei es jetzt MVC, HMVC, MVP oder ein komplett anderes Entwurfsmuster) das Bugfixing, eben weil sich ein Entwickler sofort bzw. mit wenig Einarbeitungszeit zurecht findet und die Zusammenhaenge verstehen kann.

Es macht aber einen Unterschied, ob ich nur an einer Stelle nachsehen muss, oder im ungünstigsten Fall an drei Stellen. Ich habe halt gerne Alles auf einen Blick und nicht zerhackstückelt. Die Trennung von Logik und Layout lasse ich mir aus Gründen der Flexibilität gefallen, aber noch zwei weitere Schichten? Gerne ohne mich. Und in statischen Umgebungen trenne ich nichtmal Logik und Layout.

Roger Wilco wrote:
Joe User wrote:Weil man zwar recht günstig von "einfachen Strukturen" (siehe oben) zu MVC migrieren kann, aber nur sehr teuer zurück.

Das haelt sich bei einer hinreichend komplexen Anwendung die Waage. Wir sprechen ja sicherlich nicht vom 08/15 Hello World Programm.

Ich spreche zum einen von simplen Webanwendungen bis hin zu komplexer industrieller Steuerungs-, Mess- und Antriebstechnik.

Roger Wilco wrote:
Joe User wrote:Für mich ist MVC eben nur ein Hype, ging ja jahrzehntelang auch ohne MVC sehr gut.

Stimmt, warum gab es nach C eigentlich noch weitere Programmiersprachen? Man konnte ja jahrzehntelang und kann noch immer sehr gut damit entwickeln.

IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.
Alle anderen Sprachen bringen keine echte Verbesserung gegenüber diesen Beiden.

Roger Wilco wrote:
Joe User wrote:PS: Warum nutzen Assembler-Programmierer kein MVC, wenn es so toll ist? ;)

Weil nicht jedes Entwurfsmuster zu jedem Problem passt. Du benutzt ja auch kein Proxy-Pattern, wenn du eigentlich ein Visitor-Pattern willst. Oder ein Factory-Pattern, wenn du eigentlich ein DTO willst.

Es gibt durchaus viele Bereiche wo man sich als Assambler-Programmierer an MVC halten könnte, aber Assambler-Programmierer sind im Allgemeinen nunmal darauf Bedacht effizient zu programmieren und MVC scheint dem entgegen zu stehen.

Ich konnte bisher wirklich keinen einzigen Vorteil von MVC gegenüber konventionellen Programmiertechniken finden. Entweder waren Beide gleich gut geeignet, oder MVC hatte Nachteile (meist nur leichte, aber eben auch wenige schwere).
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by daemotron » 2010-09-12 13:49

MVC ist sehr universell und geht weit über Spring MVC, Struts, Django, RoR, Symfony und wie sie alle heißen hinaus - auch wenn heute gleich jeder an eines dieser Frameworks denkt, wenn von MVC die Rede ist. Gerade Django und RoR (Symfony kenne ich nicht hinreichend, um darüber urteilen zu können) interpretieren MVC sehr stark in eine Richtung und schränken es auf ein bestimmtes Schema ein (ORM als Model, URL-Mapping als Controller und HTML-artige Templates als View).

Dass das Konzept eigentlich generischer ist, zeigt ein Blick auf ältere Frameworks (wie Struts) oder Anwendungen, die ohne Framework geschrieben wurden*. MVC ist in erster Linie an den natürlichen Lebenszyklus eines HTTP-Requests angelehnt. Der Controller entscheidet darüber, wie ein Request zu beantworten ist, der View ist das zurückgelieferte Ergebnis, und im Model steckt ggf. weitere Logik, die der Controller bei der Bearbeitung des Requests heranziehen kann.

*Java-Webanwendungen z. B. verwenden klassischerweise Servlets als Controller und JSPs als Views. Die Anwendungslogik wird in zusätzlichen Klassen implementiert, die dann das Model bilden.
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by daemotron » 2010-09-12 14:16

Joe User wrote:So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Damit folgst Du ja bereits dem MVC-Pattern - Deine Funktion/Klasse/Macro/etc ist der Controller, die verwendeten Skin-Bestandteile sind der View. Was Dein Controller dann noch zusätzlich holt (z. B. DB-Abfragen) sind das Model - bei PHP-Anwendungen z. B. ist das DB-Handling ja bereits in einem der RDBMS-Module wie mysqli o. ä. gekapselt.

Joe User wrote:Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Für einen Hype ist MVC IMHO mittlerweile zu alt. Ich würde da eher von best practice sprechen...

Joe User wrote:IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.
Alle anderen Sprachen bringen keine echte Verbesserung gegenüber diesen Beiden.

Einspruch, Euer Ehren :wink: BASIC halte ich für völlig verzichtbar, genauso wie Perl, Java, C# und so weiter. Jedes Problem lässt sich letztlich in Maschinensprache lösen; wer die Befehlssätze der Prozessoren kennt, braucht also nicht mal Assembler 8)

Aus Produktivitätsgründen braucht man jedoch Abstraktionen von Assembler bzw. Maschinencode. Diese Abstraktion muss dem zu lösenden Problem angemessen sein. Möchte ich ein Betriebssystem schreiben, muss ich gezwungenermaßen nahe am System bleiben. Eine mögliche verwendbare Abstraktion ist dann C. Möchte ich hingegen ein komplexes linguistisches Problem lösen, wäre wohl Lisp oder Erlang eine angemessenere Abstraktion.

Was ich damit verdeutlichen will: Sinn und Zweck einer Abstraktion vom Maschinencode-Level ist es, dem Entwickler die Möglichkeit zu geben, sich mehr auf das logische Problem zu konzentrieren. Die Hauptschwierigkeit ist dabei IMHO, die angemessene Form der Abstraktion zu wählen. Hierbei greifen aber selbst professionelle Programmierer häufig genug ins Klo.

So findet man beispielsweise textverarbeitende Programme wie Editoren, Spellchecker etc., die in C geschrieben sind - in dem Code findet man vor lauter malloc()s die eigentliche Logik nicht mehr. Hier wäre es angemessen gewesen, eine Abstraktion zu wählen, die dem Programmierer das Speichermanagement erspart.

Umgekehrt gibt es auch so idiotische Dinge wie eine X.500-Implementierung in Java - bei Baumstrukturen kommt es jedoch auf effizientes Speichermanagement an, was durch eine virtuelle Maschine und das Konzept der Garbage Collection so gut wie nicht zu realisieren ist.

Wenn man über die Vielfalt der Programmiersprachen urteilt (was hier eigentlich auch schon wieder OT ist :wink: ), sollte man im Hinterkopf behalten, dass Programmiersprachen als Abstraktion oft genug für die Lösung eines speziellen Problems geschaffen wurden - und hinterher von Dritten zweckentfremdet eingesetzt werden.
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Roger Wilco » 2010-09-12 16:51

Joe User wrote:So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Jesco hat es schon geschrieben: Damit hast du fast den View aus dem Model-View-Controller Entwurfsmuster implementiert. MVC formalisiert das Ganze nur (wie auch schon erwähnt) unabhängig von der eingesetzten Technologie.

Joe User wrote:Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Design Patterns sind über das Stadium eines Hypes schon lange hinaus. Letztlich sind es Best Practices und ich bin sicher, dass auch du in deinen Entwicklungen schon das ein oder andere Entwurfsmuster angewendet hast, ohne es vielleicht zu wissen.

Joe User wrote:Es macht aber einen Unterschied, ob ich nur an einer Stelle nachsehen muss, oder im ungünstigsten Fall an drei Stellen.

Das ist der Punkt: Du musst nicht an drei Stellen nachsehen. Dafür sind Modell, Sicht und der Controller getrennt und haben komplementäre Aufgaben. Wenn du etwas am Aussehen der Anwendung ändern willst, wirst du das in der View machen. Willst du etwas an dem Datenmodell ändern, machst du das im Model und wenn es an die Geschäftslogik gehen soll, änderst du diese im Controller.

Joe User wrote:IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.

„Jedes Problem in der Informatik lässt sich durch eine weitere Indirektionsschicht lösen.” ;)

Joe User wrote:Es gibt durchaus viele Bereiche wo man sich als Assambler-Programmierer an MVC halten könnte, aber Assambler-Programmierer sind im Allgemeinen nunmal darauf Bedacht effizient zu programmieren und MVC scheint dem entgegen zu stehen.

Assembler ist vor allem keine objektorientierte Programmiersprache. Viele Design Patterns wurden mit OOP im Hinterkopf entwickelt. Man kann verschiedene Entwurfsmuster zwar auch mit nicht OO-Programmiersprachen umsetzen, im schlimmsten Fall kämpft man dann aber gegen die Sprache.

Joe User wrote:Ich konnte bisher wirklich keinen einzigen Vorteil von MVC gegenüber konventionellen Programmiertechniken finden.

Das MVC-Muster ist eine konventionelle Programmiertechnik, die bspw. in Swing oder den MFC zum Einsatz kommt.
Last edited by Roger Wilco on 2010-09-12 16:52, edited 1 time in total.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-12 17:34

daemotron wrote:
Joe User wrote:So wie bei MVC auch: Ich übergebe meiner Funktion/Klasse/Macro/etc den Namen des Skins. So funktionieren nahezu alle Template-Engines.

Damit folgst Du ja bereits dem MVC-Pattern - Deine Funktion/Klasse/Macro/etc ist der Controller, die verwendeten Skin-Bestandteile sind der View. Was Dein Controller dann noch zusätzlich holt (z. B. DB-Abfragen) sind das Model - bei PHP-Anwendungen z. B. ist das DB-Handling ja bereits in einem der RDBMS-Module wie mysqli o. ä. gekapselt.

Demnach gab es MVC bereits lange vor MVC, nur hat es damals keine Hype-Bezeichnung gehabt ;) Also ist MVC doch nur ein Hype 8)

daemotron wrote:
Joe User wrote:Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Für einen Hype ist MVC IMHO mittlerweile zu alt. Ich würde da eher von best practice sprechen...

Best practice war es nach obigen Definitionen bis es die Hype-Bezeichnung MVC bekam. Damit kann ich leben und halte mich dann lieber an best practice als an MVC ;)

daemotron wrote:
Joe User wrote:IMHO bräuchte man nur zwei Programmiersprachen:
Assambler für Experten und BASIC für den Rest.
Alle anderen Sprachen bringen keine echte Verbesserung gegenüber diesen Beiden.

Einspruch, Euer Ehren :wink: BASIC halte ich für völlig verzichtbar, genauso wie Perl, Java, C# und so weiter.

Abgesehen von BASIC stimme ich Dir zu ;)

daemotron wrote:Jedes Problem lässt sich letztlich in Maschinensprache lösen; wer die Befehlssätze der Prozessoren kennt, braucht also nicht mal Assembler 8)

Richtig, wobei ich noch echtes Assembler meine, also die hardwarenahste Lowlevel-Programmiersprache, nicht diesen neumodischen hochsprachenähnlichen Quatsch ala nasm und Co.

daemotron wrote:Aus Produktivitätsgründen braucht man jedoch Abstraktionen von Assembler bzw. Maschinencode. Diese Abstraktion muss dem zu lösenden Problem angemessen sein. Möchte ich ein Betriebssystem schreiben, muss ich gezwungenermaßen nahe am System bleiben. Eine mögliche verwendbare Abstraktion ist dann C.

Wenn ich mir ansehe, was wir In-House mit Assambler Alles produktiv (schnell und nahezu bugfrei (6 Bugs in 25 Jahren)) lösen und welchen Aufwand echte C-Profis für das gleiche Ergebnis, sofern überhaupt möglich, betreiben müssen, da wundere ich mich über das Hardware-Wettrüsten nicht mehr im Geringsten.
Beispiel: 64Bit Wurzelroutine für einen 8Bit-Atmel-Microcontroller mit grosszügigen 4kb Speicher. In Assambler absolut kein Problem, in C unmöglich.

daemotron wrote:Was ich damit verdeutlichen will: Sinn und Zweck einer Abstraktion vom Maschinencode-Level ist es, dem Entwickler die Möglichkeit zu geben, sich mehr auf das logische Problem zu konzentrieren.

Wo liegt denn für einen C-Programmierer in vorigem Beispiel das logische Problem und wie erschlägt er es?

daemotron wrote:Die Hauptschwierigkeit ist dabei IMHO, die angemessene Form der Abstraktion zu wählen. Hierbei greifen aber selbst professionelle Programmierer häufig genug ins Klo.

Full-ACK

daemotron wrote:Wenn man über die Vielfalt der Programmiersprachen urteilt (was hier eigentlich auch schon wieder OT ist :wink: ), sollte man im Hinterkopf behalten, dass Programmiersprachen als Abstraktion oft genug für die Lösung eines speziellen Problems geschaffen wurden - und hinterher von Dritten zweckentfremdet eingesetzt werden.

Was zumindest auf BASIC nicht zutrifft, denn BASIC wurde als einfach zu erlernende Allzweckwaffe entwickelt und das ist auch weitestgehend gelungen. Man denke nur mal an den C64 zurück und vergleiche die damaligen BASIC-basierten und heutigen C-basierten Applikationen gleichen Funktionsumfangs. BASIC schneidet dabei zu geschätzten >95% besser ab, sowohl von der Wartbarkeit des Codes als auch von der Ausführungsgeschwindigkeit des Programms.

Hmm, vielleicht bin ich ja auch nur zu konservativ...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-12 17:46

Roger Wilco wrote:
Joe User wrote:Das gilt für altbekannte Prinzipien erstrecht, warum also einem Hype folgen?

Design Patterns sind über das Stadium eines Hypes schon lange hinaus. Letztlich sind es Best Practices und ich bin sicher, dass auch du in deinen Entwicklungen schon das ein oder andere Entwurfsmuster angewendet hast, ohne es vielleicht zu wissen.

Richtig, aber ich brauchte dafür kein Buzzword/Hype ;)

Roger Wilco wrote:
Joe User wrote:Es macht aber einen Unterschied, ob ich nur an einer Stelle nachsehen muss, oder im ungünstigsten Fall an drei Stellen.

Das ist der Punkt: Du musst nicht an drei Stellen nachsehen. Dafür sind Modell, Sicht und der Controller getrennt und haben komplementäre Aufgaben. Wenn du etwas am Aussehen der Anwendung ändern willst, wirst du das in der View machen. Willst du etwas an dem Datenmodell ändern, machst du das im Model und wenn es an die Geschäftslogik gehen soll, änderst du diese im Controller.

Wo schaue ich denn bei einem simplen Anzeigefehler wie kaputten Umlauten/Sonderzeichen nach? Im View/Template, weil das Template-File falsch kodiert ist? Im Model, weil die Zeichensätze falsch gehandhabt werden? Im Controller, weil die Zeichen bereits falsch im DBMS sind? Wo fange ich an, wo höre ich auf?

Roger Wilco wrote:
Joe User wrote:Es gibt durchaus viele Bereiche wo man sich als Assambler-Programmierer an MVC halten könnte, aber Assambler-Programmierer sind im Allgemeinen nunmal darauf Bedacht effizient zu programmieren und MVC scheint dem entgegen zu stehen.

Assembler ist vor allem keine objektorientierte Programmiersprache. Viele Design Patterns wurden mit OOP im Hinterkopf entwickelt. Man kann verschiedene Entwurfsmuster zwar auch mit nicht OO-Programmiersprachen umsetzen, im schlimmsten Fall kämpft man dann aber gegen die Sprache.

Will man OO wirklich haben? Frage mal einen echten Assembler-Programierer. Der schlägt die Hände überm Kopf zusammen ;)
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-12 17:59

Da fällt mir spontan "Automotive Erfahrung" ein, schönes Buzzword und Keiner kann es genau erklären ;)
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-12 18:15

Hmm, ich bin schon öfter Auto gefahren und habe auch manche Schäden selbst repariert, also habe ich "Automotive Erfahrung"?
Nee, ernsthaft, schau Dich mal auf Jobbörsen um und frage die suchenden Firmen mal, was das Buzzword bedeutet. Entweder bekommst Du gar keine, oder eine völlig bescheuerte, weil unpassende, Antwort darauf. Macht Spass ;) Nichtmal direkt in der Automobilbranche bekommt man vernünftige, einheitliche Antworten darauf und die sollten es eigentlich genau wissen.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Roger Wilco » 2010-09-12 18:17

Joe User wrote:Demnach gab es MVC bereits lange vor MVC, nur hat es damals keine Hype-Bezeichnung gehabt ;) Also ist MVC doch nur ein Hype 8)

Quanten gab es schon lange vor der Quantentheorie. Ist die Quantentheorie deshalb ein Hype? Nur weil etwas formalisiert wird, wird die Sache dadurch noch lange nicht zum Hype.

Du solltest auch nicht vergessen, dass Entwurfsmuster hauptsächlich deshalb entwickelt bzw. aus den Best Practices formalisiert wurden, damit Entwickler über die gleichen Dinge reden können. Denn ohne Namen bzw. Bezeichnung kann man über Dinge nicht reden. Wenn ein hinreichend erfahrener Entwickler über das Singleton Pattern redet, weiß ein anderer Entwickler i. d. R. sofort, was dieser meint. Ebenso ist es mit dem MVC Pattern: Ein Entwickler weiß, was ein anderer Entwickler damit meint und wie die Architektur einer Anwendung oder einer Komponente, die dieses Muster implementiert, abstrakt aussieht.

Joe User wrote:Wo schaue ich denn bei einem simplen Anzeigefehler wie kaputten Umlauten/Sonderzeichen nach?

Bei dem von dir dargelegten Ansatz müsstest du ebenso in dem Skript (ggf. den verwendeten Bibliotheken), den Templates und der Datenbank nachsehen. Hier hat das MVC Pattern an sich also keinen Nachteil.

Joe User wrote:Will man OO wirklich haben?

Will man Assembler wirklich haben? Man kann doch jeden Mikrochip direkt programmieren und braucht keine unnötigen Indirektionsstufen wie Assembler. ;)

Joe User wrote:Frage mal einen echten Assembler-Programierer. Der schlägt die Hände überm Kopf zusammen ;)

Dann lass einen Assembler-Entwickler mal eine relationales Datenbanksystem programmieren. Oder eine größere Finanzanwendung wie von Banken benutzt. Oder ein hinreichend komplexes verteiltes System. Oder ein simples Textverarbeitungsprogramm mit WYSIWYG. Der schlägt die Hände überm Kopf zusammen.

Natürlich ist das möglich. Das folgt allein schon aus der Tatsache, dass die meisten Assembler turingkomplett sind. Aber das bedeutet noch lange nicht, dass es sinnvoll ist, Assembler für diese Art von Anwendungen zu verwenden.
Last edited by Roger Wilco on 2010-09-12 18:19, edited 1 time in total.

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by daemotron » 2010-09-12 22:26

Um das ganze mal ein bisschen aufzulockern:
http://cafedegeek.com/2225/programmer-hierarchy/

Joe User wrote:Wenn ich mir ansehe, was wir In-House mit Assambler Alles produktiv (schnell und nahezu bugfrei (6 Bugs in 25 Jahren)) lösen und welchen Aufwand echte C-Profis für das gleiche Ergebnis, sofern überhaupt möglich, betreiben müssen, da wundere ich mich über das Hardware-Wettrüsten nicht mehr im Geringsten.

Das wäre dann wohl so ein Fall mit der falschen Wahl der Indirektionsstufe. Die Aufgabe von C ist historisch eine ganz andere gewesen: Programmlogik nur einmal schreiben müssen und dann auf verschiedener Hardware kompilieren und ausführen können. Mit Assembler völlig undenkbar. Stell Dir mal vor, der Apache Webserver müsste für jede Plattform separat in Assembler ausprogrammiert und maintained werden... von den verschiedenen Konventionen zum Aufbau eines lauffähigen Programms auf den unterschiedlichen Betriebssystemen ganz zu schweigen (EXE, COM, ELF, A.OUT, ...), und die unterschiedlichen Syscalls machen dann auch ganz viel Spaß...

Joe User wrote:Beispiel: 64Bit Wurzelroutine für einen 8Bit-Atmel-Microcontroller mit grosszügigen 4kb Speicher. In Assambler absolut kein Problem, in C unmöglich.

Grundsätzlich ist die Kompilierung von C zu Assembler umkehrbar. Zu einem gegebenen Stück Assembler-Code lässt sich auch ein Stück C-Code finden, das nach den Regeln der Grammatik von C genau wieder in dem vorgegebenen Stück Assembler-Code abgebildet würde (Bezeichner mal außen vorgelassen). Allerdings ist das Finden eines passenden Code-Stücks nicht trivial und kann auch in abartigem, unleserlichem Code enden, der mit großer Wahrscheinlichkeit plattformabhängig sein wird - eben genau das, wofür man C typischerweise nicht einsetzt.
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-12 23:35

daemotron wrote:Um das ganze mal ein bisschen aufzulockern:
http://cafedegeek.com/2225/programmer-hierarchy/

Nice, wobei der Teil zwischen JavaScript und Java IMHO eher auf Höhe von C++ anzusiedeln ist. Der Rest passt ;)

daemotron wrote:Stell Dir mal vor, der Apache Webserver müsste für jede Plattform separat in Assembler ausprogrammiert und maintained werden...

Wäre kein allzu grosses Problem, da Letzteres auch jetzt schon der Fall ist und Ersteres nichtmal mehr Entwickler bedeutet, sondern nur andere Entwickler, die eben hin und wieder Datasheets lesen müssen. Dafür wäre der Apache extrem effizient ;)

daemotron wrote:von den verschiedenen Konventionen zum Aufbau eines lauffähigen Programms auf den unterschiedlichen Betriebssystemen ganz zu schweigen (EXE, COM, ELF, A.OUT, ...), und die unterschiedlichen Syscalls machen dann auch ganz viel Spaß...

Syscalls interessieren einen Assembler-Programmierer nicht, er programmiert schlicht direkt die Hardware, am Kernel vorbei. Deswegen sind RootKits in purem Assembler aus dem laufenden System heraus auch nicht feststellbar. Im Bereich der Industriespionage ist das seit dem letzten Jahrtausend durchaus gängige Praxis.

daemotron wrote:
Joe User wrote:Beispiel: 64Bit Wurzelroutine für einen 8Bit-Atmel-Microcontroller mit grosszügigen 4kb Speicher. In Assambler absolut kein Problem, in C unmöglich.

Grundsätzlich ist die Kompilierung von C zu Assembler umkehrbar. Zu einem gegebenen Stück Assembler-Code lässt sich auch ein Stück C-Code finden, das nach den Regeln der Grammatik von C genau wieder in dem vorgegebenen Stück Assembler-Code abgebildet würde (Bezeichner mal außen vorgelassen). Allerdings ist das Finden eines passenden Code-Stücks nicht trivial und kann auch in abartigem, unleserlichem Code enden, der mit großer Wahrscheinlichkeit plattformabhängig sein wird - eben genau das, wofür man C typischerweise nicht einsetzt.

In diesem Fall reichen die 4kb Speicher für den C-Code und das zugehörige Hauptprogramm schlicht nicht aus. Von ein paar unter C unmöglichen Griffen in die tiefe Hardware-Trickkiste mal ganz abgesehen, haben wir dank Assembler noch Einiges an Speicher frei. In Assembler hat unsere Wurzelroutine IIRC <100 Byte und arbeitet auch noch mit getesteten 128Bit, vermutlich auch deutlich höher (wir brauchen nur 32Bit). Wohlgemerkt auf einem 8Bit-Microcontroller.
Atmel wollte die Routine auf Grund der Effizienz so gar direkt in Hardware giessen, hat dies meines Wissens nach aber auf Grund mangelnder Nachfrage noch nicht getan.


Naja, genug abgeschweift...

Halten wir also fest: MVC ist ein Buzzword für jahrzehntelange Best Practice und ich habe mich dank des jüngeren Hypes um MVC etwas in die Irre leiten lassen. #:-s
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by daemotron » 2010-09-13 09:29

matzewe01 wrote:Ich frage mich blos, woher Du den jüngeren Hype hast.

Das ist für mich schon nachvollziehbar - MVC wurde in letzter Zeit im "Consumer"-Bereich (kleinere Webanwendungen wie Bords, Wikis, etc.) schon ziemlich gehyped - einfach indem sich diverse Frameworks für den privaten und semiprofessionellen Bereich das Label "MVC" aufgepappt haben.

Joe User wrote:Syscalls interessieren einen Assembler-Programmierer nicht, er programmiert schlicht direkt die Hardware, am Kernel vorbei.

Das geht aber z. B. nicht besonders gut, wenn sich mehrere Prozesse die Ressourcen teilen müssen. Und bei den von Dir angeführten Hacks ist es durchaus interessant, die Syscall-IDs des angegriffenen Kernels zu kennen (klassisches Beispiel wäre etwa ein Shellcode-Exploit mit NOOP-Slide, wie etwa bei den Acrobat- und Flash Exploits neulich).

OK, bei Problemen, die mit Assembler gelöst werden, ist es schon eher üblich, gleich ganz ohne Betriebssystem zu arbeiten - gerade im Embedded-Bereich kann man sich den Overhead aus Scheduler, Prozesstabelle etc. schon speichertechnisch gar nicht erst erlauben...

/me geht dann mal weiter seine Webanwendungen in C schreiben :P
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: MVC - Fluch oder Segen? (was: SeCoTo auf dem Weg zurück?

Post by Joe User » 2010-09-13 10:39

daemotron wrote:
matzewe01 wrote:Ich frage mich blos, woher Du den jüngeren Hype hast.

Das ist für mich schon nachvollziehbar - MVC wurde in letzter Zeit im "Consumer"-Bereich (kleinere Webanwendungen wie Bords, Wikis, etc.) schon ziemlich gehyped - einfach indem sich diverse Frameworks für den privaten und semiprofessionellen Bereich das Label "MVC" aufgepappt haben.

Das und einige Stellenanzeigen im nicht-Java-Bereich. Ich mache um Java einen genauso grossen Bogen wie um Debian ;) , daher war mir das Alter der Bezeichnung "MVC" tatsächlich nicht bewusst.

Egal, danke Euch für die Nachhilfe.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.