Bullshit Bingo: Heute MVC und DB's

Und ich kann alles stehen lassen wie es steht - die Wahrheit ist manigfaltig.

Ich sage ja im Prinzip nichts anderes - man muss eben abwägen ob man den Framewürgsumpf folgen will.

Ich kritisiere nur den Framework-Markt - wo die Dinge i.d.R. als Allheilmittel verkauft werden - und das oft ohne jegliche Kritik (die liest man ab und an mal als Randnotiz in irgendeinem Block weil jemand abstinkt)

Ein Framework selbst bauen halte ich selbst sowieso für die interessanteste aller Aufgaben beim Entwickeln - wenn man die Zeit hat (und sich das zutraut) sollte man das tun. Natürlich darf man gucken was andere machen - was man erben will - was man nicht will.

Und ich hab auch gesagt, dass man selbst mit diesem Weg sicher 2 - 3 mal geerdet werden muss - bis da auch was schickes entsteht. Man hat vor allem selbst Einfluss auf “die Architektur” … eigentlich ist sowas das richtige für nen Vollblut-Entwickler/Informatiker - Probleme abstrahieren.

Das schöne am Eigenbau: Man kann den persönlichen Geschmack einfließen lassen - und (wo es erlaubt ist) auch schonmal sehr Spezifische funktionen unterbringen - wo allgemeine Frameworks sich das nicht erlauben können - und dann für den speziellen Programmierer so wahnsinnig kompliziert werden.

marc will halt die absolution von uns, dass es schon ok ist, eben NICHT total auf diese Frameworks abzufahren" … marc - meine hast du :slight_smile: - aber angucken lohnt sich immer

Du hast natürlich prinzipiell recht, ads aber wir müssen bei der Diskussion
auch beachten das wir hier von einem speziellen Anwendungsfall, nämlich WebApplikationen sprechen. Die simple WebApplikation ist mit Sicherheit eine
HTML-Seite. In der steht dann enfach nur Text und nichts weiter. Das Protikoll zum holen ist HTTP 1.1

Beispiel:
GET Welcome! - The Apache Software Foundation HTTP/1.1

Um serverseitig skripten zu können benötigt man einen dynamischen html
generator der die Post und Gest Requests mit möglichst wenig Overhead
komfortabel handelt. Es liegt in der Natur der Sache, das alles das was den Post oder Get Befehl verzögert sich schlecht auf die Auslieferzeit der
eigentlichen Seite auswirkt. Besonders drastisch wird es, wenn jemand
das HTTP, das für großangelegte, asyncrone Auslieferung von HTML und
anderen Dateiresourcen ausgelegt wurde versucht auszuheleb und mit dder
serverseitigen Skriptsrache eine Art zweites HTTP 1.1 nachzubauen und so
gewissermaßen einen (z.B PHP Webserver auf HTTP versucht zu implementieren). Da ganze hat zwar Charme, nur wurde PHP oder Perl für sowas einfach nicht entwickelt. Das wäre ja so als würdest Du versuchen
Tetris so lange aufzubohren bis es ein Handybetriebssystem wird.

Wie auch immer: Die ganzen fortschrittlichen Techniken die WebServer wie
Apache oder Lighttp2 beherrschen um eine möglichst gut GET / POST Performance zu erzielen (Threading, Forking, Memmanagement, Bandbreite
pro zustandsloser COnnection wird ab ad surdum geführt und ein Zustand
erschaffen der so nicht Gedacht war. Wem simples HTTP für seine WebApplikation nicht mehr reicht und der wirklich diese Serverseitigen
Veredlungen wie MVC will sollte dann doch einen WebServer b.z.w WebApplicationserver nehmen der für genau diese Betriebsart auch erdacht
und implementiert wurde. Ein derartigen Server gibt es derzeit nur im Java (Servler/JSP-Bereich) und er heisst Tomcat (Jetty geht auch). Tomcat ist ein eigenständiger, in Java geschrieber Webserver der aber bereits MVC artige
Dinge von Haus aus beherrscht und im Rahmen der J2EE Spezifikation im Rahmen seiner Servletcontainer Definition erfüllt. Wenn eine derartige Verarbeitungsweise wirklich erwünscht ist, dann sollte man sich ernsthaft
Gedanken machen einen Server wie Tomcat zu nutzen oder aber einen völlig neuen “WebApplicationserver” zu entwickeln der dann einfach mehr kann als
HTTP Requests bedienen (denn das ist es nun mal wozu Apache2 und Co entwickelt wurden).

Das mag alles sein, geht aber Meilenweit am Topic des Forums vorbei…


Andreas

Das Topic ist “Programmierung”, von daher passt das schon.

Aber im von dir gequoteten Text wird sich über einen Zustand aufgeregt, der einfach mal eine Lösung für ein existierendes Problem darstellt. HTTP kann kein Stateful, also muss das irgendwie implementiert werden. Ich verstehe jetzt die Aufregung darum nicht …

Also Tomcat resp. JSP/Servlet Container leisten eigentlich nicht viel mehr als ein dummer Webserver …

Sie mappen HTTP requests so ziemlich 1 zu 1 in eine Java Umgebung … sind also eher eine softwaretechn. Infrastruktur. Du hast halt zugriff auf die Anfrage und kannst den Output generieren. Also so ein Tomcat implementiert im Grunde nur HTTP(s) - mehr nicht. Du musst in der Java-Umgebung immernoch große Teile der Regeln des HTTP - Protokolls beachten.

Sowas würde ich mal noch kein Framework für Applikationen nennen.

Wenn Du Java programmieren willst, dann wirst du wohl kaum HTTP implementieren wollen - also steht es in der regel ausser frage einen Tomcat oder was adäquates zu nutzen.

Doch! Und genau das wahr ja der Grund für das Aus von mod_jk respektive
JServ. Die Idee hinter diesen Apache Modulen wahr es ja eine Art mod_php / mod_perl als mod_java eben für Apache zu implementieren. Es at nict wirklich gut geklappt also haben sich die Apacheleute die Servlet Referenzengine
von SUN geschnappt und die Resourcen von JServ in Tomcat eingebracht.

Tomcat selber macht aber auch eine ganze Menge mehr als z.B Apache2.
Apache2 ist wie gesagt auch nur ein Webserver, der nun mal HTML Seiten
ausliefen soll. Tomcat kann das zwar auch, hat aber die Catalina ServletEngine und die JSP Engine Jasper an Bord die zu, Gesammtkonzept des Servers gehören. Gemäss der J2EE Spezifikation können z.B die JSP und Servlet Klassen JNDI Verbindungen auf entfernte, EJB-BusinessLogic Server etablieren und machen damit eine verteilte, Komponentenorientierte Anwendungsarchitektur möglich. Wenn man statt Tomcat (der ja nur eine Submenge der J2EE Soezifikation abbildet) durch einen richtigen AppServer wie z.B JBoss, GlassFish oder Websphere ersetzt in dem Tomcat oder eine Tomcatähnliche Alternative implementiert ist, hat man das alles schon im Bundel und man benötigt keine Fremdserver oder Thirdparty Komponenten mehr. Zend versucht so etwas auch schon lange hinzubekommen, Microsoft auch aber derzeit gibt es sowas nur im Javabereich und das wird wohl auch noch lange so bleiben.

Aber zurück zu MVC. Es macht aus meiner Sicht keinen Sinn sich für einen Server zu entscheiden der nicht das leistet was man benötigt.Der Versuch die fehlenden Serverfeatures auf Applikationsebene nachzuholen wird wohl immer an der Performance scheitern, besonders wenn viele konkurierende Verbindungen etabliert werden, deswegen setze ich es nicht gerne ein und mag es auch nicht besonders, denn überall wo es zum Einsatz kommt hat man es mit einem lahmen Gaul zu tun der fortwährend Siesta macht und was daran so toll sein soll, kann ich nicht erkennen.

Leute, ihr habt die Diskussion schon kreuz und quer angefangen, indem ihr MVC als Trennung zwischen Code und Design auf der einen und Abstraktion von Datenbankklassen ala PDO & Co. auf der anderen Seite zusammen in einen Topf geworfen habt!

Jetzt wird auch noch Java & Co. in den gleichen Hexenkessel gepackt.


Könnt ihr die einzelnen Themen bitte mal auftrennen und einzeln diskutieren? Alles andere macht keinen Sinn, weil ihr über drei verschiedene Sachen lästert.

Wer nach 5 Projekten es immer noch nichts verstanden hat und im 6. Projekt von Bullshit schreibt, zählt wohl nach Deinem Verständnis zu den guten Programmierern!



mfg

fristo

War das eine kompetente Äusserung zur Sache oder eher ein Flameversuch?
Müssen wir uns jetzt sogar schon über derartige Ergüsse hier auslassen?

Wer hat wohl diesen Thread mit genau den von dir soeben kritisierten Äußerungen angefangen?

nunja - es macht grundsätlich keinen sinn, irgendwas einzusetzen, das nicht leistet - was man benoetigt.

diese aussage ist zu durchwachsen, als dass man sie einfach so bestätigen koennte. “Applikations-Ebene” - was soll das sein? Applikation ist ein logischer Begriff - Server eher ein “physischer” (auch wenn man bei “Server” von Software spricht). “Applikation” findest du bei einer fertigen Lösung quasi überall. Das ist halt das zeug, was vorher nicht da war und nun dazuimplementiert wurde.

Nebenläufigkeit ist eine Disziplin, bei der Sprachkonstrukte helfen sie zu bestreiten. Man muss sich halt über Architektur Gedanken machen - ein Apache Tomcat nimmt Dir das Denken nicht ab, auch keine andere Abstraktion wie JBoss oder so Zeug.

Natuerlich produzieren Frameworks eine Menge Overhead. Wäre ja auch dumm wenn sie nix machen würden. Die Idee bei so einer Geschichte ist v.a. Skalierbarkeit und Wartbarkeit. D.h. wenn Du Dich auf die Philosophie einlässt wirst Du die Lernkurve bestreiten müssen. D.h. Du musst schon ein bisschen wissen wie die Dinge arbeiten. Sich dafür grundsätzlich nicht zu interessieren wäre in etwa so fatal wie - wegen Javas GC nicht wissen zu wollen, wie dessen Speichermanagement ablaeuft.

Die Ziele der genannten Frameworks sind v.a. bessere Skalierbarkeit und Wartbarkeit. Die Mechanismen (sofern man sich daran haelt) sind recht statisch - der Entwickler wird zum Programmierer. Es gibt eine Menge Erfahrungen überall zu finden (freilich muss man filtern). Man kann recht gute Aussagen über Projektverläufe treffen - Natürlich nicht als Einsteiger.

Ich mag diese Frameworks auch nicht sonderlich - weil ich kein Programmierer bin - und ich mein Aufgabengebiet eigentlich genau dort sehe - wo diese Frameworks meinen mir Lösungen bieten zu können. Mit denen bin ich eben auch nicht zufrieden - und mir macht das tüfteln viel Spass ich mag diese Disziplin einfach gern selbst bearbeiten und kanns nur immerwieder empfehlen wenn man Zeit dafür hat.

Dito. Wenn man sich mal alle Schichten vor Augen führt die Layer für Layer ablaufen müssen bis das ganze dann mal als Maschinencode läuft, kann einen ganz schwindlig werden. Ich habe das immer auf dem Zettel und übernehme keine Garantieren für diese aufgeblasenen MVC WebApzz da sie gerade im PHP Bereich teilweise ein unberechenbares Verhalten an den Tag legen. Das debuggen und z.B mit DTrace durchleuchten wo nun genau der Hase im Pfeffer liegt ist Schwerstarbeit. Teilweise bypassen die z.B eigentlich intelligente Dinge wie OpCode Caches weil sie meinen sie könnten es auf Highlevelebene
besser… das musst man erstmal spitzkriegen weil so etwas nicht mal dokumentiert ist. Und als nächstes haben solche Dinge wie APC oder ZendCache dann auch noch ihre Eigenarten, Störpotential und Co. Da lobe ich mir Java. Ein Bytecode, eine VM, eine GC die aus dem gleichen Stall kommt und wo nicht alles wie Frankysteins Monster zusammengeklatscht wird und kein Sch… hinterher mehr weiß obs überhaupt tut.

Update: Und es geht weiter :smiley:

Ich bin jetzt gerade mal durch das Feedback Forum einer großen Website
gegangen die einen Relaunch auf Basis des MVC-Frameworks Symfony on
gestellt hat.

Die Leute im Forum überschlagen sich mit Postings, aber keine guten ;d
Die meisten finden die Site-Performance inakzeptabel und drohen ihre kostenpflichtigen Premium Accounts zu kündigen wenn es sich nicht bessert.
Well, da sind zig Server und Squid Proxies vorgeschaltet und sogar ein NGIX HTTPd läuft auf der Frontseite, daher gibts beim statischen Content fast
keine Probleme, aber wehe man will sich einloggen, ein Userprofile öffnen
oder auf eine Instantmessage antworten, dann kracht es gewaltig und die Ladezeiten gehen teilweise bis an die 30 Sek. Das Backend ist ein MySQL5 Cluster aber der Objectmapper mit seiner autogenerierten META Abfrage
die dynamisches SQL generiert versaut wohl so ziemlich jedes Executionplaning den der verzweifelte Optimizer von MySQL (der dem von
PG haushoch unterlegen ist) .

Die alte Seite war zwar auch nicht der Performancebringer, seit Symfony
und MVC ist die Seite in existentielle Probleme geraten. Mehr Hardwarepower
nutzt auch nichts. Ich schätze das wird ein harter Aufprall und Lehreffekt.

Gott lob war ich diesem Zeugs schon immer kritisch gegenüber eingestellt
und programmiere lieber soliden, eigenen Code. Dann weiß ich zumindest das die Sachen auch laufen und muss nicht beten und dem Performancegott Brandopfer darbieten ;D

Das AJAX Dillema

Update2;

Das ist einfach köstlich. Bei Ajax war ich ja lange auch geteilter Meinung, aber
offensichtlich gibt es bei Laptop Usern auf der tollen, neuen Symfony MVC Seite einen signifikanten Einsatz von AJAX+JavaScript. Effekt: Die Implementierung von JavaScript im Firefox scheint bei deren Scripts so intensiv zu werden, das der Laptop ins glühen gerät und sich stark erhitzt!

Ich bin auch manchmal auf solche Seiten geraten, habe da aber nur flüchtig
drüber nachgedacht, aber jetzt wo andere das breitbandig einsetzen und sich
diese Phänomene häufen werde ich für meine Sites lieber beim guten alten CGI Modell bleiben und JavaScript und Ajax nur sparsam einsetzen ;D Man bin ich froh das ich nicht auf diese Hypes reingefallen bin, ich war knapp davor ;D