Bullshit Bingo: Heute MVC und DB's

Hallo,

Sicher haben hier einige von euch mal MVC Frameworks ausprobiert und mit den lustigen, Objektrelationalen Mappern (z.B PHP = PDO, .NET Entity Framework, Java = Hibernate und CMP, Perl = Catalyst und Mason) rumexperimentiert oder seid in Projekten involviert gewesen wo das genutzt wurde.

Die Frage ist für mich nur allen ernstes, wozu? Der Zielclient für WebAppz ist
fast immer ein WebBrowser, da macht es keinen Sinn das Layout von der
Programmlogik trennen zu wollen, b.z.w dafür reichen die Tags die z.B PHP oder JSP bieten vollständig aus und wenn es in Richtung DB geht macht es noch weniger Sinn. Die O DB Mapper sind ein generalistischer Ansatz der das
SQL vor dem Programmierer verbergen soll, ohne das es die Besonderheiten
der DB berücksichtigt. So etwas kann natürlich nur in schlechten Queries und üblen Exectutionplans münden und die Gesammtanwendung unerträglich verlangsamen. Anstatt dann hinterher her zu gehen und die kritischen Stellen
dann mit schmutzigen Tricks zu optimieren baste ich doch lieben meinen Code selber und ich weiß es läuft am Ende auch wirklich! Ich habe nun 5 Projekte gehabt wo immer MVC am Ende die Problemstelle an sich wahr und ich wahr mehr damit beschäftigt die Frameworks zu überlisten um die Performance in den Griff zu bekommen als mit irgend etwas anderem. Manchmal ging es sogar soweit das wir unglaublich teure Hardware angeschafft haben die dann die
Probleme brachial durch pure Hardwarepower erschlagen haben - ABER das kann es ja wohl kaum sein!!

Mir graust vor dieser anrollenden Welle von lauter MVC gestruckten Sites
die da gerade gebaut werden. Es ist, als ob man dem Teufel direkt ins Antlitzt blickt…

Das beste Framework nützt nichts, wenn der Programmierer nichts taugt (generelle Aussage, keine persönliche Anspielung auf irgendjemand)

Solche Frameworks nutzen nur etwas, wenn man auch weiß was man macht. Desweiteren lohnt es sich auch nicht umbedingt für jedes Projekt diese einzusetzten. Aber gerade bei größeren Projekten, wo auch sehr viele Leute daran arbeiten, bringt das oft schon etwas. Außerdem erleichtern diese auch teilweise die Wartung von Programmen.

Der Ansatz von den Frameworks ist an sich ganz gut. Diese sind ja meist daraus entstanden, dass ein Projket die Anforderung hatte, dass eine Trennung vorgenommen werden musste, weil es vllt am Ende auf “irgendwelchen” Datenbanken landet.
Aber wie progs schon sagte nuetzt das Framework nix, wenn das Projekt dafuer ungeeignet ist.
Wenn man von vornherein weiss, es laeuft nur auf zwei oder einer Datenbank, dann kann man sich die Vebrindung auch selber schnell zusammen basteln. Aber wenn es nur eine kleine Software wird, wo man weiss, dass es nicht auf Performance ankommt, warum nicht sowas benutzen und mal schnell zusammen kloeppeln?
Rails gefaellt mir auf jeden Fall sehr, aber ich werd es nicht fuer meine grossen Projekte benutzen. Da warte ich erstmal ab, wie Rails3 wird, weil das sehr beschleunigt werden soll, aber erstmal guggn.
Ansonsten bleib ich dabei alles selber zu schreiben, dann hab ich wenigstens die Gewissheit, dass es an mir liegt.

Falsch! Schlechten Programmierern wird es erst möglich durch derartige Frameworks und Assistenten getriebenes
“visuelles” WebApplikations zusammengeklicke den Grundstein des Desasters zu legen. Meist wird sowas von sogenannten Softwarearchitekten vorgelegt und dann behauptet man müsse ja nur noch die Rümpfe ausprogrammieren und dann würde alles super laufen - aber nichts ist weiter von der Realität entfernt als diese Aussage.

Das Problem steckt im MVC Ansatz selbst. Was nutzt es wenn ein Controller “Requests” des Clients verarbeiten soll (vor allem wenn die Verarbeitung sowieso nur serverseitig stattfindet) und diese Requests durch zig Highlevel API’s und Eventques geschleust werden müssen um ein simples HelloWorld! in einem HTML Dokument auszugeben wenn dabei durch das Framework ennorme CPU, RAM und Netzwerkresourcen belegt werden und damit die overall Performance in den kritischen Bereich absinkt? Hast Du Dir mal die Mühe gemacht von extern anzuschauen was da an last erzeugt wird und wie sich das im konkurierenden Connections in der Realität “live” auswirkt? Gerade wenn i18n und zig tausende “unsichtbare” (weil intelligent)
XML Parser Zugriffe ablaufen wird es unerträglich bei mehr als 20 Usern in so gut wie jedem MVC Frontend.
Wo ist der “produktive” Unterschied ob ich nun in einer PHP Seite entweder <?php print(“Hello World”); oder <expression_lang_xyz>Hello World!</expression_lang_xyz> Der Ouput ist der gleiche nur das ich bei MVC dann etwa 100% mehr Hardware und OS Resourcen verschwende und wenn es irgendwo knallt kaum noch nachvollziehen kann wo der Fehler bei dem autogenerierten code eigentlich steckt.

Aber gerade bei größeren Projekten, wo auch sehr viele Leute daran arbeiten, bringt das oft schon etwas. Außerdem erleichtern diese auch teilweise die Wartung von Programmen.

Nee, sorry das erleichtert gar nichts, ausser am Anfang die vage Hoffnung hier irgendwo Zeit sparen zu können .Am Ende verballerst Du dann die Zeit eben bei der Fehlersuche, Bugreports und Dich über MVC generell zu Tode zu ärgern. Ich bin nach 10 Jahren aktiver WebApplikationsentwicklung fest davon überzeugt das MVC ähnlich wie SOAP und SOA eine absolut katastrophale Fehlentwicklung ist und einzig und alleine dazu dienlich ist Codemonster und Coderuinen zu produzieren, die je nach Skill entwender nur grauenvoll oder komplett inakzeptable Ergebnisse bescheren und ich erlaube mir nach 5 Majorframeworks einfach mal diese Aussage das man ohne MVC bei jeder WebApplikation besser dasteht als mit
(mit der ich übrigens auch nicht ganz alleine dastehe).

Also die Trennung von Code und Design sollte schon sein, ansonsten entsteht unübersichtlicher Code. Was PHP mit seinen integrierten Tags anbietet ist imho der größte Schwachsinn, den sich jemand ausgedacht hat.

Ob man nun die Funktionalität der Datenbank(klasse) vom Rest der Anwendungslogik trennen muss und unabhängig und portabel entwickelt - sei jedem selbst überlassen. Ich persönlich mag diesen generellen Ansatz überhaupt nicht, dadurch wird imho viel Potenzial verschwendet.

Aber was seitenweise Texte und HTML-Quellcode in der Anwendungslogik verloren hat, verstehe ich nicht.

Unter Python klappt das wunderbar sowohl mit SQLAlchemy als auch mit Django. Letztlich befreit es mich davon, einige Dinge zweimal machen zu müssen. Klar hat man einige Einschränkungen, was die ‘reine’ SQL-Lehre angeht, aber es kommt halt drauf an, wo die Schwerpunkte sitzen. Eine High-Performance-Anwendung möchte ich auch nicht damit erstellen müssen, bei einem CMS ist es schon ein große Hilfe. SQLAlchemy erlaubt es dir z.B. auch auf deine selbst zusammengebaute Datenbank zuzugreifen. Speziell die Trennung von Logik und Design klappt unter Python auch recht gut, von PHP hab ich allerdings keine Ahnung.

Grüssle Uwe

Naja, aber das gibt es schon andere Möglichkeiten außer MVC. Java z.B (Servlets/JSP) macht schon seit Jahren (alternativ) sehr erfolgreich vor.
Ich habe eine oder mehrere Java Klassen, die kompiliere ich und packe sie dann in eine Zipdatei mylib.jar (kann man mit jedem ZipTool öffnen).

In meiner JSP Datei (*.php bei Java) kann ich nun die Klassen aus der
Jar Datei einbinden (was in PHP ein “include” ist.

Beispiel: helloworld.jsp
<%@page contentType=“text/html” pageEncoding=“UTF-8”%>
<%@page import=“java.util., myPackage.myClass.” %>

<jsp:useBean id=“my” class=“myClass” scope=“session”/>
<jsp:setProperty name=“my” property=“*”/>

blah <%= myClass.sayHello()%>

Das ist jetzt normaler HTML Text!

<% for (int i = 0; i < 10; i++) {
%>
Antwort: <%=myClass.sayHello()%>
<%
}
%>

Das bedeutet ich kann in der Funktion “sayHello” in der Klasse “myClass”
alles berechnen, suchen und zur DB schicken und Abfragen und nur Punktuell
gebe ich im bereits fertigen Design die Ergebnisse aus, ganz ohne MVC, ganz
ohne Template Toolkit und ganz ohne Expression Language - weil Java das alles schon von Haus aus kann.


Was PHP mit seinen integrierten Tags anbietet ist imho der größte Schwachsinn, den sich jemand ausgedacht hat.

Sagen wir es mal so. Alles muss in Seiten hinterlegt werden oder aber man macht sich an den Overkill und baut sich eigene Module in C/C++ die man dann am Webserver installieren muss um so etwas ähnliches wie die Session
Beans in Java zu bekommen.

Ob man nun die Funktionalität der Datenbank(klasse) vom Rest der Anwendungslogik trennen muss und unabhängig und portabel entwickelt - sei jedem selbst überlassen. Ich persönlich mag diesen generellen Ansatz überhaupt nicht, dadurch wird imho viel Potenzial verschwendet.

Ich bin auch ein großer Fan davon die Daten auch wirklich in der DB
aufzubereiten, notfalls auch durch eigens implementierte UDF’s in C/C++
aber bei Postgres hat man ja so schöne Dinge wie pl/pgsql und daher
reicht das in 90% aller Fälle meist aus (was man von MySQL ja nicht gerade behaupten kann).

Aber was seitenweise Texte und HTML-Quellcode in der Anwendungslogik verloren hat, verstehe ich nicht.

Das ist ja die Philosophie von MVC Frameworks, nur das die Methode um das zu erreichen auf denkbar schlechte Art und Weise realisiert wurde. Es macht für mich so gut wie keinen Sinn, eine Art Server für den Server zu haben, der
die Unzulänglichkeiten des Webservers ausgleichen soll (eigene Ques, eigene Events und eigenes Exceptionhandling) das dann Highlevel viele Stufen durchlaufen muss und wo dann meist auch noch ge xmlt wird das die Schwarte kracht! Das ist doch klar das sowas 1000 mal langsamer ist als ein PHP print “Hello”;

Fairnesshalber muss man aber für mein obiges Beispiel anmerken, das der Webserver auf dem Java Server Pages laufen nicht der Apache1/2 oder Microsoft IIS ist sondern der Apache Tomcat, ein eigener in Java geschriebener Webserver der für die Art der Verarbeitung völlig neu erdacht und als kleiner Applikationsserver entworfen wurde und deshlab natürlich perfekt angepasst ist an den Java Kosmos und daher auch so schnel (allerdings ist die Performance auch schnell wieder dahin wenn ich auch dort MVC einsetzen würde und da gibts ebenfalls genug dreckszeugs)!

Dir ist aber schon klar was ein automatisch generiertes

SELECT * FROM

ANSTATT:

SELECT spalte FROM tabelle [LIMIT { zahl | ALL }] [OFFSET zahl

Unterscheidet oder? Kann ja sein das Dir das Ding das generieren des hochkomplexen Statements SELECT * FROM abnimmt aber was dann am
Ende in der Realität passiert steht auf einem ganz anderen Blatt. Die SQL Implementierung von Postgres als auch pl/pgsql erwarten von dem jeniegen
der die SQLAbfrage erstellt das er weiß was er da macht - ein Automat kann das unmöglich wissen und das Endergebnis ist in 99% Desaströs! Klar werden die Tabellenspalten gemappt und Serialisierung klappt auch toll - aber: Zu welchen Preis? Wenn das jeder mit seiner Website machen würde, dann hätten wir bald
wieder die Geschwindigkeit beim Seitenaufbau wie in den 90er Jahren mit 14.000er Akustikmodem!

Zumindest unter SQLAlchemy habe ich die Möglichkeit, auch direkt mit SQL-Statements zu arbeiten, Aber das eigentlich ist auch kein Webframework. Bei Django gebe ich dir recht, da kann ich das nicht so einfach.
Aber wenn eine solche Anforderung auftaucht, habe ich eventuell auch das falsche Werkzeug. Framework sind nicht die Lösung für alles, aber für manches eine feine Sache. Und der, ders bedient, sollte schon was davon verstehen.

Gruß Uwe

Hallo marc9022,

ich bin ja allgemein kein Freund von Webanwendungen, weil ich sie zum größten Teil überflüssig (bzw. als ‘normale’ Anwendung besser finden würde), aber auch ich bin letztens über Django gestolpert und bisher schwer begeistert.

Vielleicht verstehe ich ja auch etwas in diesem Thread falsch, aber ich kann dir nicht ganz folgen. Wenn ich das richtig verstehe gibst du den MVC-Frameworks die Schuld, die würde ich aber nicht mit den O/R-Mappern gleich setzen.
Django besticht dadurch, dass es eine wirklich strikte Trennung der Logik (also des Python-Codes) und der Views gibt. Ich bin zwar noch recht frisch in der Thematik, fühle mich da aber ingesamt sicher aufgehoben. Der View ist eine HTML-Datei in der eine Art Makro-Sprache Platzhalter für den variablen Teil abbildet. Das ist sauber zu lesen und man kann sich sehr gut in fremde Projekte einarbeiten. Das mal unabhängig zur Datenbankanbindung.

Mit Hibenate hatte ich unter Java das ein oder andere Mal zu tun. Der größte Vorteil den ich darin gesehen habe: man ist komplett unabhängig von der Datenbank wenn man will. Es gibt durchaus Situationen in denen das sinnvoll sein kann (wenn man einem Kunden z.B. mit einem freundlichen Lächeln erzählen kann, dass seine bereits vorhandene Datenbank auch unterstützt wird).

Den Methodenaufruf innerhalb einer HTML-Datei wie du ihn hier in dem mayClass.sayHello()-Beispiel zeigst empfinde ich als eher unsauber. Selbst ohne eingesetztes Framework würde ich versuchen die Logik unter allen Umständen von der Anzeige zu trennen. Das wird doch sonst eine riesige Friemelarbeit

Gruß
Sparrow

Lies noch mal alles genau durch, besonders der Hinweis zum Thema Expression Language, den sayHello ist nichts anderes als das was deine Makros da machen, andere nennen es eben Expression Language.

Desweiteren würde ich PHP PDO nicht als objektrelationelen Mapper bezeichnen. PDO passt hier nicht wirklich rein. PDO ist einfach eine andere Art, Datenbankunabhändig zu sein, Prepared Statements ausführen zu können, etc. Es erspart mir das ständige wechseln von mysql_query zu pgsql_query, etc. und ich kann einfach alles mit $pdo->query() ausführen. Es liefert mir aber keine Objekte im eigentlich Sinne zurück (außer evtl. $pdo->fetchObject(), aber das ist ja das gleiche wie mysql_fetch_object, pgsql_fetch_object()).

  1. verschwendete Zeit
  2. nix für Freunde von vernünftigen Datenmodellen

wer ORMapper nutzt ist selber schuld

außerdem sollte man ORMapper nicht mit MVC-Frameworks verwechseln.

Du hast 100% Recht Symbiont. Allerdings kommen ORM und MVC’s fast immer
in einem Bundle daher und manche MVC Frameworks erlauben oder wollen es nicht das man anders auf die DB’s zugreift und dann gibts keinen Support und Hilfe von Seiten des Herrstellers mit der Begründung selber schuld. Also indirekt sind die beiden Themen extrem verzahnt - obwohl das wohl das der
MVC Pattern gar nicht vorschreibt, aber egal.

Tatsache ist das MVC sämtliche Requests durch eigene Event und Processing
Ques schickt (zumindest die existenten Frameworks) und da kannst Du Dir ja vorstellen was passiert, wenn z.B ein PHP Skript sich vor die HTTP Aufrufe
mogelt und versucht Webserver zu spielen, die Anfragen umbiegt und durch XML-Parser jagt, dann einen ORM Mapper involviert, ein SELECT * FROM auf die DB Tabellen macht und am Ende dann Hello World ausgeben soll. Das ganze taugt nichts. Und wenn ich eigene Wege gehen will um die Ideen
der MVC und ORM Hilfsmittel auszutricksen (Workarrounds) dann muss man sich doch fragen - wozu der ganze Stress? Ich für meinen Teil bleibe da lieber native, bei von mir geschriebenen Code und schnellen Antwortzeiten (vielleicht wird das ja irgendwann mal ein neues (altes) Qualitätskriterium für Websites - das sie einfach schnell sind).

man liest ständig die Quacksalberei diverser Autoren zu diesem Thema

allesamt versprechen Sie das IT-Paradies

nur Grau ist jede Theorie … und so farblos auch die vorhandenen Frameworks … welcher Art auch immer.

im Grunde verkaufen Sie “uns” wertlose Glasperlen, und das leider mit Erfolg. Weil es kaum Leute gibt die sich selbst um Frameworks kümmern - eigene neue/bessere Ansätze probieren und entwickeln. Das braucht nämlich auch Zeit und reichlich Erfahrung. Damit das dann auch noch gut wird - brauchts insgesamt noch 2 bis 3 Ernüchterungen - dazu noch Mut den ollen Mist wegzuwerfen für neue Anläufe.

Die existierenden Frameworks können nicht “toll” sein, weil sie auf dem Reisbrett enstanden sind und nach und nach um Lösungen für Unzulänglichkeiten erweitert. Gut - sie funktionieren - nur das tut ein antiquierter Bollerwagen auch.

Was Dir also bleibt ist zu überlegen wofür Du Deine Zeit einsetzt

  1. Die mühevolle Lernkurve für so ein Framework auf dich zu nehmen.
  2. Was eigenes konstruieren.

zu 1. die oft propagierten Vorteile sind auch nur scheinbar - nehmen wir mal das J2EE Spec … angeblich kann man ja seine Applikation voneinem Container in einen anderen transferieren - nur wer tut das ernsthaft? Wenn es überhaupt geht - 80% dieser Applikationen kann man nicht transferieren weil sie dann doch spezielle API des verwendeten Containers oder deren Konventionen anwenden.

Es ist aber sicher nicht falsch zu wissen, worums insgesammt geht - wie es denn funktioniert. Wie ich gern sage - sie kochen alle nur mit Wasser.

Die existierenden Frameworks können nicht “toll” sein, weil sie auf dem Reisbrett enstanden sind

Das kann ich nicht so stehen lassen, denn zumindest Rails, Merb und Django sind aus Projekten hervorgegangen und wurden Nachtraeglich daraus extrahiert.
Gerade bei Rails mag es aussehen, als ob es zuerst auf dem Papier entstanden ist, aber da dort so viel wie moeglich ueber Konvention statt ueber Programmierung abgewickelt wird, macht es sehr gut bedienbar.
Die Performance hat zwar in den letzten Jahren gelitten, aber das wird mit Rails3 bedeutend anders. Merb hatte den Schwerpunkt vor allem auf Performance und benutzte den selben Ansatz wie Rails, Konvention kommt zuerst. Fuer Rails3 werden diese beiden Frameworks zusammen gelegt und momentan sieht es sehr vielversprechend aus, was da am Ende raus kommt.

Jedes Framework hat seine Berechtigung, genauso wie jede Programmiersprache. Ob es gut ist oder nicht, sei mal dahin gestellt, aber viele entstehen einfach aus dem Grund, weil sie gebraucht werden. Aber so wie man mit jeder Sprache unsinn treiben kann, wuerde ich nicht unbedingt sagen, dass die Frameworks oder MVC daran schuld sind, dass alles unperformant wird. Das ist doch auch immer von anderen Faktoren abhaengig.

Sorry aber das ist Unsinn und Symbiont hat recht. Du bist sicher einer dieser jungen Programmierer mit ganz wenigen Jahren Praxis und deshalb weißt Du es einfach nicht besser. Wir aber sind leidgeprüfte Praktiker die mehr als nur ein MVC Framework gesehen haben und dabei ernüchtert festgestellt das sie bei noch so vielen Sprachen und Platformen einfach am Ende nichts weiter als
ein Klotz am Bein sind der nicht hilfreich sondern eher das Hindernis ist - das Problem dabei sind dann Leute wie Du, die es eben einfach nicht wahrhaben wollen. Denen glaubt dann irgend eine Niete im Nadelstreifenanzug und das nächste, große Softwaredesaster wird freudestahlend in Angriff genommen - bis es knallt! Und dann will es wieder keiner gewesen sein (wie immer)!
Solche Sachen haben zwei Seiten: Sie müssen gut durchdacht und in der Realität, im operativen Geschäft wirklich das leisten was erwartet wird. Niemanden kratzt ob die TemplateEngine was verbockt hat oder der ORM Mapper den DB-Server bis ans Maximum stresst. Am Ende sehen die Verantwortlichen einfach eine träge, lahme Softwaresau die nicht funktioniert und dann helfen keine noch so guten Ausreden mehr, dann muss man geradestehen für so ein Desaster. (Nicht glauben: Du musst wissen das es funktioniert und zwar unter realen Bedingungen - ganz ohne phantasterrein).

Das wiederum kann ich nicht so stehen lassen :wink: . Ich bin zwar kein Programmierer und nicht jung, aber nutze trotzdem gerne Frameworks, wenn sie meine Arbeit erleichtern. Aber ich gebe dir auch recht, vieles daran ist unpraktisch oder undurchdacht, oft auch im teuer zu bezahlenden Bereich (wo die Leute sitzen, die es sich leisten können, fernab von Pragmatik und Usability was am Reißbrett zu entwickeln). Aber liegt es denn nicht in meiner Verantwortung als Entwickler oder Systemarchitekt aus den gegebenen Anforderungen das richtige Framework zu suchen und die richtigen Test zu formulieren? Und wenn ich keins finde, mir halt die Umgebung so zurecht zu schneidern, das es passt? Für die Entscheidung muß man dann natürlich auch die Verantwortung übernehmen.

Gruß Uwe

Ich habe schon ganz am Anfang gesagt, dass MVC-Frameworks kein Allheilmittel sind, aber sie sind auch nicht das abgrundtief Boese.
Man kann doch keine Sprache oder Framework blind links einsetzen, in der Hoffnung, dass schon alles Funktionieren wird. Du wuerdest bestimmt auch nicht Lua benutzen um einen Treiber zu programmieren und genauso wenig wuerde ich momentan ein Framework einsetzen um irgendeine grosse Applikation zu schreiben, wo ich genau weiss, dass am Ende haufenweise Leute damit arbeiten muessen und Performance einfach das ist, was ich am dringensten brauche.
Frameworks sind doch auch nur ein Arbeitsmittel, die irgendwann mal entstanden sind, weil sie gebraucht wurden, was bei Rails definitiv der Fall ist.
Und wenn eine Entscheidung in Richtung einer Sprache oder eines Frameworks zu treffen ist, dann kann ich die auch gegenueber Kunden oder Chefs auch tragen.
Und nur weil ich Frameworks verteidige, heisst das nicht, dass mir die Erfahrung fehlen wuerde, diese richtig einschaetzen zu koennen :wink: Denn ab wann hat man denn genug Erfahrung? Wenn man 20 Jahre Informatiker ist und immer noch mit Basic arbeitet?

edith hat noch was zu sagen: Selbst wenn du schon einen Haufen Frameworks gesehen hast und welche Fehler man damit machen kann, kann dir das ja auch dabei helfen den Leuten zu sagen, wie man diese Fehler vielleicht vermeiden kann, ohne das man irgendwelche dreckigen Tricks anwenden muss.

Gut, kehren wir das Spiel doch mal um:

ihr Kritiker programmiert sicher alle noch mit Assembler, denn jede Hochsprache ist ein Framework, um die Hardware und die Details des Prozessors zu abstrahieren. Außerdem entwickelt ihr pro Programm immer alle Funktionen neu - inkl. des Betriebssystems. Weil auch das OS ist eine Abstraktionsschicht.

Fehdehandschuh und so