PHP vs. ColdFusion

ohio hat gesagt.:
@holy
wie schaut das genau aus mit den komponenten, worin unterscheiden sich php & asp denn im businessbereich?

Komponenten sind Softwarebausteine.
ActiveX (COM) Komponenten z.b ist die MS-Lösung davon,
weibei COM / ActiveX nicht gerade berühmt für Sicherheit sind.

In Java gibt es Serverseitige Komponennten "Enterprise Java
Beans" die für Serverseitige Anwendungen genutzt werden kann.
Es geht insbesondere bei EjB's um das verteilen von Anwwendungen.
Sprich grosse Seiten wie z.b Amazon.com oder ähnliches sind
normalerweise verteilte Applikation.
Das bedeutet die Applikation wird auf mehrere Server aufgesetzt.

Mann spricht von sogenannten n-tier Applikationen.
Zumeist gibt es 3 Schichten:
Daten - Businesslogic - Ansicht
Wobei die Daten schicht z.b. eine Datenbank ist inclusieve
Applikationen für den Datenzugriff (z.b. EntityBeans) .
Businesslogic representiert die eigentliche Programmlogic,
das verarbeiten der Daten, z.b bei Amazon die Bestellung eines
Buches und die dadurch in gang gesetzte Logic wie z.b Nachbestellen
beim Buchlieferant usw.
Die Ansicht ist letztendlich das was ihr hier mit PHP Programmiert zumeist. Es geht darum die Daten anzuzeigen, das HTML Dynamisch zu verändern usw.

PHP ist stark in dem letzten Punkt. Oder aber bei kleinen Webseiten
für alles zusammen.
Aber PHP hat z.b Starke beschränkungen, wenn es z.b um die Zusammenarbeit mit Legacy Applikationen geht oder andere Businessapplikationen. Versuch mal mit PHP auf SAP Daten zuzugreifen
usw.
Das heisst mann kann die Arbeit trennen.
Applikationen in Java geschrieben für die Logic, eine gute Datenbank (Oracle, DB2 z.b) + Stored Procedures für die Daten.
Die Logic gibt die Daten in ein für beide lesbares Format an das Frontend weiter, welche dann diese Daten presentiert.

wieso, weshalb, warum? hat das was mit den entwicklungsumgebungen zu tuhen oder einfach an der tatsache, dass php nicht das zeug hat, wie wird php5 sich eventuell darauf auswirken?

Nun Entwicklungsumgebungen sind nett,
aber nicht wirklich ein Kriterium dafür.

Wenn die PHP Entwickler weiter versuchen PHP als Eierlegende-Wollmilchsau zu "verkaufen" dann sehe ich keine positive Entwicklung.
Die PHP Entwickler sollten die Stärken von PHP weiter auszubauen.
Und das heisst RAD Entwicklung von Views.
 
SonicBe@m hat gesagt.:
das ist ganz einfach
welche sprachen lassen es zu platform unabhängig zu laufen?
1. platform unabhänig -> ich brauch mich nicht darum zu kümmern obs nen linux win oder max sys sein soll da meine funktionen immer gleich sind also hab ich auch keine beschränkung auf welchem sys ich das installiere

Ich bin als Java Programmierer und durch 1 Rechner Linux und 1 Rechner Win privat ja auch ein verfechter von Plattformunabhängigkeit. Aber dies spielt im Serverseitiger Programmierung nicht wirklich eine Rolle.
Da mann den Server nicht wirklich jeden Tag wechselt. Zudem ist
Apache mit mod_php eigentlich auf soziemlich allen Plattformen zuhause.

2. das komplete java api -> ich habe somit die möglichkeit wirklich komplexe sachen zu erstellen... -> optimierer für aktien z.b. ;) und das im web.. mach das mit php und du bekommst nen anfall *G*
Nun grundsätzlich hast du recht,
nur wird dir javax.swing bzw java.awt in deinem Servlet nicht viel helfen ;)

3. biste nicht nur an das web gebunden und kannst somit auch applets schreiben oder gui anwendungen oder aber auch consolen anwendungen

auch wenn es schwerer als php ist
einmal java immer java! ;)
Java ist nachdem mann OOP wirklich verstanden hat, einfacher als PHP,
da geradliniger.
 
öhö.

was prädestiniert denn java für oop? warum nicht C/C++/C# statt java?

kennt ihr TOP, table oriented programming, habe selbst leider noch nicht viel erfahrung damit machen können, dennoch hört sich die logik dahinter um einiges ökonomischer an als OOP. im grunde geht es nunmehr darum code und programmstrukturen über tabellen zu verwalten. dies birgt unter anderem den vorteil, dass die tabellen im gegensatz zum code 2 dimensional sind. vielleicht interessiert den ein oder anderen ja diese seite von b. jacobs -> http://www.geocities.com/tablizer

ich finde hoch interessant.
 
Re: öhö.

ohio hat gesagt.:
was prädestiniert denn java für oop? warum nicht C/C++/C# statt java?

Es gibt kein Grund weshalb nicht C++ oder C# für OOP.
Wir reden aber nicht über OOP, sondern über serverseitiger Programmierung.
Und da ist Java als gegen Bufferflows Sicherste Sprache besser geeignet.
Zudem sind die Netzwerkfähigkeiten von Java ziemlich heftig, und Java hat sich jahrelang weiter entwickelt als die Sprache der Wahl für Entfernte aufrufe.

RMI, RPC, EjB gibts schon ne ganze Weile
und stellt industriestandard für Verteilte Applikationen da.

Ein weiterer Punkt ist wohl die Unterstützung von Java durch die grössten Software-Schmieden:
IBM, Oracle, Sun Microsystems, BEA, SAP
Borland Inprise setzen alle auf Java.

IBM und BEA verdienen sich dumm und dähmlich mit ihrem IBM Websphere bzw
BEA Weblogic Application Server. Auch Borland und Oracle mischen da mit.
Nun ausser Microsoft, die haben jahrelang auch Java ihres Hauptfeindes Sun unterstützt (was ja für Java ansich spricht) und nun mit .net eine "alternative" geschaffen.

Das ganze Konzept von .net ist so in der Art schon in Java vorhanden.
ASP.net ist JSP / Servlets
Taglibrarys abgeschaut und das Framework
ist abgeschaut. C# code ist fast Quellcodekompatibel zu Java code, sosehr das Java Entwickler nach 1 Woche unterschiede zu C# herausarbeiten danach sovort Produktiv auch .net und C# programmieren können.
Jedoch ist .net relativ neu, und muss erst beweisen das es eine wirkliche Alternative darstellt.

kennt ihr TOP, table oriented programming, habe selbst leider noch nicht viel erfahrung damit machen können, dennoch hört sich die logik dahinter um einiges ökonomischer an als OOP. im grunde geht es nunmehr darum code und programmstrukturen über tabellen zu verwalten.
Halte ich für ein Schritt in die falsche Richtung.
Es gibt andauernd irgendwelche neuüberlegungen. Aspekt Orientierte Programmierung hört mann auch immer häufiger, wenn sich da was durchsetzt schau ichs mir an. Aber das meiste ist Schall und Rauch.
 
Halte ich für ein Schritt in die falsche Richtung.
Es gibt andauernd irgendwelche neuüberlegungen. Aspekt Orientierte Programmierung hört mann auch immer häufiger, wenn sich da was durchsetzt schau ichs mir an. Aber das meiste ist Schall und Rauch.

falsche richtung? welche richtung ist richtig'er?

das argument es gäbe andauern neuüberlegungen zieht nicht.

1. basiert TOP auf P/R programmierung, zB C geeignet
2. ist TOP nicht neu, auch weil es ebend nicht Datenorientiert handeln muss
3. hört sich es sich nach dir so an als ob nur das sich durchsetztende auch das richtige ist, die masse macht keine qualität.
 
Original geschrieben von ohio
falsche richtung? welche richtung ist richtig'er?

das argument es gäbe andauern neuüberlegungen zieht nicht.

1. basiert TOP auf P/R programmierung, zB C geeignet
2. ist TOP nicht neu, auch weil es ebend nicht Datenorientiert handeln muss
3. hört sich es sich nach dir so an als ob nur das sich durchsetztende auch das richtige ist, die masse macht keine qualität.

Nein das heisst nur das ich nicht auf jeden neuen Zug aufspringe weil 99 % davon sich als unpraktisch herausstellt.

Wenn ich von vielen Seiten höre das dieses oder jenes sehr gut ist, so weckt es auch mein Interresse wie im Augenblick ich mich für Ruby interressiere, da ich viel gutes höre.

Wenn ich über Tabellen Orientiertes Programmieren viel gutes von verschiedenen Quellen denen ich traue höre, dann wird sich auch mein Interresse dahingehend wandeln :)

Aber im Augenblick weiss ich nur welche Schwierigkeiten die Tabellarische Speicherung von Daten mitsich bringt, und es eher ein Weg gesucht wird für ein gesunden Workaround zum OOP Zugriff auf Daten, wie z.b die JDO oder EntityBeans.
 
gut, wills dabei belassen, wobei ich doch gerne näheres über die "Schwierigkeiten die Tabellarische Speicherung von Daten mitsich bring"en wissen würde, und wie schaut so ein gesundes workaround aus?
 
Das problem ist das mann will man Objecte in Relationale Datenbanken speichern, diese soweit zerlegen muss das es passt.
Object Orientierte Datenbanken sind zwar schon auf dem Markt aber nicht so leistungsfähig wie Relationale, aus diesem Grund gibt es solche Technologien wie JDO oder EntityBeans. Damit ist es möglich das Relationale Daten als Object abgebildet werden.
Du hast somit einen OOP zugriff auf Relationale Daten, was äusserst hilfreich ist.
 
Zurück