Antworten: 44
|
|||
 Micha.09  Specialist Herkunft: Dortmund Beiträge: 2860 |
# Antwort: 41 - 11.07.2011 um 11:09 Uhr
LAszlo würde sich riesig freuen wenn du Symfony2 lernst 
|
||
Inaktiv |
  |  |
||
| jokey Try to beat me  Herkunft: Hamburg Beiträge: 184 |
# Antwort: 42 - 11.07.2011 um 14:20 Uhr
11.07.2011 um 01:43 Uhr - reVerB: 11.07.2011 um 01:25 Uhr - jokey: baust du das irgendwo ein? den passenden proof of concept expolit schick ich dir dann über die seite -.- Ok das ist nun ein Kommentar, der mich dazu veranlasst, den Wunsch zu äußern, diesen Thread bitte zu schließen. Kann ich echt drauf verzichten. Dann hat das Aufschrecken ja funktioniert  Problem ist einfach, dass du in dem gesamten Thread eine durchaus sehr gefestigte Meinung von der ganzen Sache hast, diese aber auch offensichtlich, wie dir alle Beteiligten ja schrieben, doch etwas von der Realität und einer guten Umsetzung entfernt war. Deswegen habe ich zu diesem drastischen Mittel gegiffen um dir zu zeigen, dass hier was schief läuft. Der Ansatz der objektorientierten Programmierung ist zunächst einmal in allen Sprachen gleich. Die Idee besteht immer darin, dass man zusammengehörende Daten und Funktionen in einer Klasse anordnet. Sollen diese nun verfeinert werden, so geht man nach dem Prinzip vor, dass man diese Daten zu 95% übernimmt und nur seine 2-3 kleinen Änderungen hinzufügt. Dieses Konzept hat sich aber bisher in keiner der hier gezeigten Herangehensweisen auch nur im Ansatz wiedergespiegelt. Gemachte Vorschläge wurden einfach ignoriert, wegdiskutiert oder ähnliches. Weiterhin gab es bisher keine Aussagen, was das eigentliche Ziel mal sein soll und in sofern ergibt sich hier nur ein großes Ratespiel, was kein erschöpfendes Ergebnis bringen kann. Die Meta-Aussage "Ich will mir ein Framework bauen" ist genauso gut wie "Ich will eine eigene Unterkunft". Der Spielraum ist einfach viel zu groß. Wie Laszlo auch schon geschrieben hat, gibt es in PHP bereits eine gute Handvoll Frameworks, die dir grundlegende Arbeit abnehmen, du musst aber immer noch das passende auswählen. Ein Rundum-Sorglos Paket gibt es nicht, im Gegenteil. Jedes hat seine speziellen Stärken und Schwächen, die man aber jedes mal passend zum Anwendungsfall beurteilen muss. Zuletzt editiert von jokey am 11.07.2011 um 14:20 Uhr (1x Editiert) |
||
Inaktiv |
| |
||
| reVerB Thread-Ersteller Geekboy Beiträge: 1237 |
# Antwort: 43 - 12.07.2011 um 00:14 Uhr
Naja. Mein Ziel ist es, etwas spezielles für die Kommunikation zwischen Datenbank und Desktop- oder Mobileapplikation zu kreieren, das zum einen leicht erweiterbar und zum anderen eben auch schnell über ein Adminbackend Kenndaten zur Identifizierung des Clients setzen lassen. Die Schnittstelle soll ähnlich wie dem automatischen Erzeugen von Formularen die passenden Docks für die einzelnen Aufgaben bereitstellen. Die Zielgruppe sollten kleine Unternehmen sein, für die sich Rootserver an sich nicht rentieren. Man könnte zum Beispiel dafür sogar einen Ohost oder Funpic-Server nutzen (was auf Grund des fehlenden SSL's trotzdem nicht zu empfehlen ist). Da dies ein Projekt ist, was auch veröffentlicht werden sollte, habe ich beschlossen auch gleich das ganze objektorientiert umzusetzen, da zum einen schon die ersten, mit denen ich diskutiert habe das Interesse verloren haben, als ich gesagt habe, das ich das eigentlich prozedural lösen möchte. Zum anderen argumentierte man mit den Argumenten, das es objektorientiert schneller zu erweitern wäre. Das ist auch etwas, was ich grundsätzlich so unterstreiche. Das die Objektorientierung das gleiche in PHP bewirken soll, wie es schon bei Java, C#, VB.NET und Co ist habe ich mir gedacht. Allerdings ist das Proggrammieren mit diesen Sprachen um einiges klarer, da das Framework die Richtung zu mindest ansatzweise vorgibt. In PHP ist es was anderes. Während ich mit einem Formular ein Objekt mit Daten in C# fülle, kann ich es dann in eine globale Collection speichern und dann in einem anderen Formular in eine SQLite-Datenbank mit Hilfe des SQLite-Objekts speichern, in dem ich einfach nur das Objekt übergebe. Eine globale Collection muss man sich in PHP selber schreiben. Da einem aber manchmal auf dem ersten Blick nicht gleich klar ist, wie das gehen soll, fängt man an, sich das ganze zurecht zu biegen. Dann kommen auch noch solche Sachen zu, wie man nun die Unterseiten des Adminpanels bzw. des Interfaces selbst steuert. Der eine sagt, das die Lösung alá "$unterseitenobjekt = new $unterseite();" einfach unsauber ist. Der nächste sagt dann, das ein Controller-Objekt, das in jedem Modul definiert ist der Objektorientierung abträglich ist. Ich bin gerade was das angeht einfach nur durcheinander und es kotzt an. Ich bin gerade dabei, das ganze wieder prozedural zu machen, da ich das für diesen speziellen Zweck nicht einsehe, ein riesiges Framework hinter zu schnallen, nur um mich um die ganzen komplizierten Dinge nicht kümmern zu müssen. |
||
Inaktiv |
| |
||
| SCHIRI Weltmeister Herkunft: Hamburg Beiträge: 5299 |
# Antwort: 44 - 12.07.2011 um 00:47 Uhr
In C# freust du dich, dass ein Framework dir die Richtung vorgibt, aber in php willst du kein Framework benutzen? In so ziemlich jedem Php-Framework wird genau vorgegeben, wie du etwas zu machen hast. Wie ein Model auszusehen hat, wie ein Controller zu schreiben ist. Das Dispatching/Routing von der URL bis zum Controller ist so gut wie überall fertig dabei und du musst nicht einmal wissen wie es funktioniert. Was du aber willst, ist, dein eigenes Framework zu schreiben (zumindest kam es auf den letzten 3 Seiten dieses Threads für mich so rüber) und WENN du das willst, dann musst du selber wissen, wie DU das Routing UMSETZEN WILLST. Wenn du das nicht selber beurteilen kannst, was sauber ist, was du brauchst und was möglich ist, dann sehe ich den Sinn dahinter nicht, es selbst machen zu wollen. Zu sagen, dass dieser Code:
unsauber sei, ist totaler Schwachsinn, weil das nur eine einzige Zeile ist, die in keinem Zusammenhang steht. Ob es eine "saubere" Lösung ist, hängt davon ab, woher die $unterseite-Variable genau kommt und was mit dem erzeugten Objekt genau gemacht wird und so weiter... und natürlich an welcher Stelle wiederum diese genannte Zeile steht. Wenn du die irgendwo rein haust, wo es keinen Sinn macht (in eine Email-Klasse z.B.^^) dann ist das total unsauber. Allein das vorgehen eine objekt aus einem dynamischen Klassennamen zu erzeugen ist nicht unsauber, sondern eine sehr praktische Möglichkeit, die Php ja extra bietet. ps. "sauber" ist aber eigentlich auch doofes Wort. Nenn es lieber "gut strukturierter Code" und den hast du dann wenn sich effizient damit hantieren lässt und man für kleine Änderungen nur geringen oder gar keinen Aufwand betreiben muss und für große Änderungen ruhig mehr Aufwand, aber nach Möglichkeit auch nicht zu viel Aufwand betreiben muss. Es muss ja auch nicht von Anfang an alles super gut strukturiert sein, wenn du nicht weisst wie du es am besten machst. Aber wenn du irgendwann merkst, dass etwas zu viel Arbeit macht, dann ist das ein Zeichen dafür, dass am Code etwas für deine Bedürfnisse nicht stimmt und evtl nachgebesser/aufgräumt/refactored werden sollte. Wenn auch das Aufräumen riesig viel Arbeit macht, dann scheint der Fehler in der Code-Struktur noch größer zu sein und dann merkst du dir fürs nächste mal, wie du es am besten nicht wieder machst, sodass du dann etwas besser vorausschauen kannst. Wenn du hingegen merkst, dass sich etwas unerwartet leicht einbauen lässt, was eigentlich ein riesen Feature ist, dann scheint deine Code-Strukturierung gut zu funktionieren. Wenn du hier Code zeigst und wissen willst, ob der Ansatz gut ist, gehen bei mir z.B. an vielen Stellen schon die Alarmglocken, weil ich sofort 1000 Probleme sehe, die auftreten könnten, wenn man später etwas machen will, was ich mal irgendwo machen wollte oder mir vorstellen könnte, dass du vielleicht auch später etwas ähnliches vorhast. Aber das kann ich letztendlich ja nicht beurteilen. Nur du leider auch nicht, wenn du keine Erfahrung gesammelt hast. z.B. zu der Vererbung ein paar Seiten zuvor. Ich kann dir einige Gründe nennen, warum Vererbung oft eine schlechte Idee ist. Du könntest aber auch argumentieren, dass dir die Nachteile, die du dir damit einholst, egal sind, weil du dein System eh nur hierfür und dafür brauchst und es dort keine Rolle spielt. Das kannst du aber nur, wenn du genug Erfahrung damit hast. Andersrum könnte ich dir auch Gründe nennen, warum du für das Routing von der URL bis zum Controller mindestens 40 Klassen brauchst. Ob ich damit recht hab, weisst du aber nur, wenn du es schon mal ausprobiert hast und weisst was du brauchst. Also ich schlag vor du nimmst dir irgendein Framework, schaust in die Doku, guckst ob es das kann, was du dir vorstellst und benutzt es. Wenn du dann irgendwann merkst, dass es an einigen Stellen viel zu komplex ist und an anderen Stellen zu wenig kann, kannst du dir immernoch überlegen, ob du dir selber ein paar Klassen zusammen baust, die genau das machen, was du brauchst. ------------------ www.laszlokorte.de Zuletzt editiert von SCHIRI am 12.07.2011 um 01:02 Uhr (1x Editiert) |
||
Inaktiv |
| |
||
Antworten: 44
|
|||
| Sie müssen sich registrieren, um zu antworten. |
