JAVA oder .NET? - Seite 2

Seite 2 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/java_oder_net_75872/page_2 - zur Vollversion wechseln!

atrox schrieb am 23.04.2003 um 08:44

ich freue mich über jeden thread, abseits von hilferufen beide optionen haben deutliche stärken und deutliche schwächen - beide wären gut berate diese anzugehen - zur not auch unter opferung gewisser aufwärts- (bzw abwärts-) kompatibilität oder anderer heiliger kühe.
leider spielen bei der wahl der programmierplatform aber alzu oft keine ethischen oder technischen gründe, sondern wirtschaftliche und ´politische´ eine übergeordnete rolle. ;(

Yeahman schrieb am 23.04.2003 um 10:05

Zitat von atrox
leider spielen bei der wahl der programmierplatform aber alzu oft keine ethischen oder technischen gründe, sondern wirtschaftliche und ´politische´ eine übergeordnete rolle. ;(

kann ich nur voll zustimmen!

schrieb am 23.04.2003 um 10:09

nicht zu vergessen religiöse :bash:

The Red Guy schrieb am 23.04.2003 um 10:17

Zitat von the.sh3ll
.Net Stärken:
Schnelle Lernkurve für einfache bis mittelschwere Dinge.
Ausgezeichnete Entwicklungsumgebung mit entsprechend guten Tools. (OK, Fehlerhafte Software gibt es überall, aber im Prinzip ist's sehr gut.)
Extreme Bindung an nur einen Hersteller (Sicherheit, Stabilität, Kompatiblität).

.Net Schwächen:
Erlaubt es perfekt, leichtere Applikationen zu entwickeln, die man dann immer mehr erweitert, bis ein völliges Durcheinander entstanden ist. Mag hart klingen, aber in der Praxis wird man wirklich sehr dazu verleitet.
Versteckt viel vor dem Programmierer, der manchmal im Dunkeln tappt, was da eigentlich so wirklich am Server vor sich geht.
Extreme Bindung an nur einen Hersteller (Fehler, Support).
Unzureichendes Konzept für Zugriff auf Datenbank, bzw. einzig sinnvolle Möglichkeit für performanten Zugriff sind Stored Procedures, auf die direkt zugegriffen wird.

J2EE Stärken:
Sehr gute Skalierbarkeit (wenn man's richtig macht:-)
Umfangreiche Bibliotheken.
Eignet sich hervorragend um neue Technologien und Konzepte im Serverbereich zu lernen, da vieles genau definiert und spezifiert ist.
Sehr gute Tools für CASE-Softwareentwicklung oder Refactoring-Liebhaber (Eclipse etc.)
Viele Gratis-Tools von sehr guter Qualität (Ant, JUnit).
Erlaubt es viele Konzepte moderner Softwareentwicklung relativ einfach zu lernen (wenn man systematisch vorgeht), wie etwa Extreme Programming, Refactoring, Cluster-Techniken, Message-Services etc.
Für den einzelnen Programmierer eine hervorragende Möglichkeit seine Fähigkeiten zu erweitern.
Nicht nur teure Software steht zur Verfügung, auch sehr günstige (JBoss, Eclipse).
Keine Bindung an einen Hersteller.
Entity Beans für gewisse Applikationen.

J2EE Schwächen:
So umfangreich und so viel zu lernen, daß viele Programmierer oft überfordert sind.
Bessere Schulungsprogramme durch die Geschäftsleitung wären hier hilfreich.
Noch relativ kompliziert, bessere Tools, die mehr können, wären praktisch. Das ist allerdings nicht nur ein Nachteil von J2EE, gilt für alle derartigen Serverapplikationen - Microsoft versteckt's nur besser.
Entity Beans werden oft nicht sinnvoll eingesetzt

http://www.javaworld.com/javaworld/...-j2eevsnet.html
http://www.agila.info/infos/j2ee-versus-dotnet.htm

imho haben beide Technologien Stärken und Schwächen und schließlich hängt es vom Können des Entwicklers ab wie gut er diese umsetzt.

Was verstehst du unter Skalierbarkeit und warum sind .NET Apps nicht skalierbar ?

Das mit keine Bindung an den Hersteller ist Realitätsfremd bei Java. Ich hab mich schon einige Male mit einem wirklich guten Java-Entwickler über das Thema unterhalten und im Endeffekt ist die Plattformunbahängigkeit in der Praxis nicht mehr gegeben, da die Entwickler dann immer die Erweiterungen des Java Servers verwenden.

Bezüglich Bindung an den Hersteller und Support. Wo liegt das Problem bei Microsoft und Support ? Got MSDN ?

AoD schrieb am 23.04.2003 um 11:24

Zitat von Yeahman
Sorry aber ich bin nicht mal ansatzweise deiner Meinung. Ein DB Feld von Type uniqueidentifier darf sehr wohl Null sein (Ich hab 53 Tabellen, die alle Guids als PK haben, und eben auch dadurch einen Haufen FKs die NULL sind). Wenn du ein DB Feld Null setzt willst,verwend die SetXXXNull Funktion, und beim Zugriff verwendest die IsXXXNull Funktion um zu prüfen, obs funktioniert.

Ich bin deiner Meinung!! Was ich ankreiden wollte war, dass Guid und DateTime in .NET nicht null sein können. In der Datenbanken können Fremdschlüssel null sein, nur in .NET gibts für Guids kein null, sondern nur ein Guid.Empty.

Zitat von Yeahman
Desweitern hat es durch aus Sinn ein Datenbank Connection nicht solange offenzulassen, bis sie der Programmierer schliesst (Sicherheit, Performance). Für das Multiuserproblem gibts ja schliesslich die optimistischen,pessimistischen,.. Zugriffsmethode.

Auch da stimme ich zu. Bei Internetapplikationen muss man verbindungslos arbeiten. Das Problem ist, dass ich aber diese Eigenschaft nicht deaktivieren kann, sondern auf das alte ADO angewiesen bin.

Yeahman schrieb am 23.04.2003 um 12:30

Zitat von AngelOfDeath
Ich bin deiner Meinung!! Was ich ankreiden wollte war, dass Guid und DateTime in .NET nicht null sein können. In der Datenbanken können Fremdschlüssel null sein, nur in .NET gibts für Guids kein null, sondern nur ein Guid.Empty.

Nur um Irrtümer auszuschliessen, ich halte alle meine DB Daten in Datasets, und dann kann ich eben genau so drauf zugreifen, wie beschrieben.

Zitat von AngelOfDeath
Auch da stimme ich zu. Bei Internetapplikationen muss man verbindungslos arbeiten. Das Problem ist, dass ich aber diese Eigenschaft nicht deaktivieren kann, sondern auf das alte ADO angewiesen bin.

Ich bin der Meinung das es auch in Win Programmen nicht wirklich Sinn macht. (mag persönliche Preferenz sein,..) Vielleicht versteh ich das Problem nicht richtig, aber auch hier kannst du die DataSet Funktionen (Refresh, Restore,...) verwenden.

AoD schrieb am 23.04.2003 um 12:44

Zitat von Yeahman
Ich bin der Meinung das es auch in Win Programmen nicht wirklich Sinn macht. (mag persönliche Preferenz sein,..) Vielleicht versteh ich das Problem nicht richtig, aber auch hier kannst du die DataSet Funktionen (Refresh, Restore,...) verwenden.

Ich müsste jede Sekunde ein Refresh machen, damit ich eventuell vorhandene Änderungen erhalte. Und das brauche ich mit dem alten ADO nicht machen, da das dort automatisiert abläuft.

sliver33 schrieb am 23.04.2003 um 16:40

Zitat von Jedi
OpenGL und nicht 'state-of-the-art'???
*würg*

Ich kenn mich jetzt auf dem gebiet nicht so gut aus aber was ich gelesen hat unterstützt OpenGL in der jetztigen Form keine Pixel und Vertex Shader. Um diese aber trotzdem zu benutzen muss man für jeden Chip einen eigenen Code schreiben (sog. Extensions).
Bei DirectX ist dies nicht der Fall ... darum arbeiten die meisten Herstell auch nur noch mit DirectX.

spunz schrieb am 23.04.2003 um 18:19

spielzeug => directx

profi anwendungen => opengl

aus der sicht eines admin/anwender...

Yeahman schrieb am 23.04.2003 um 20:08

Zitat von spunz
spielzeug => directx

profi anwendungen => opengl

so würd ichs auch sehen

The Red Guy schrieb am 24.04.2003 um 07:50

Zitat von spunz
spielzeug => directx

profi anwendungen => opengl

aus der sicht eines admin/anwender...

Wobei man sagen muss, dass es wesentlich mehr Spielzeug als Profianwendungen gibt.

Aber prinzipiell haben eigentlich beide nichts mit .NET zu tun. Lassen sich genauso einfach oder kompliziert verwenden mit .NET wie jede andere API, die nicht in .NET geschrieben ist.