4. Was ist eigentlich C#

Was ist eigentlich C#

  • G

    Original erstellt von Shade Of Mine:
    **
    Ausser den WinForms ist doch alles an .NET standardisiert...
    **

    Gibt es eine komerzielle Portierung des .NET-Frameworks auf Unix? Komerziell wegen dem damit verbundenen Support. Ich denke, dass Support dort schon angebracht ist.

    Eine Standardisierung bringt erstmal garnichts, wenn es keine entsprechenden Produkte gibt. ...man braucht auch nicht immer eine Standardisierung. Bei Java ist z.B. nichts bei einer Standardisierungsorganisation standardisiert, trotzdem ist es auf dem Servermarkt erfolgreich.

    0
  • H

    Original erstellt von Scania V8:
    [QB]
    [quote]Zudem kann man bei C# noch garnicht absehen, wie es sich entwickeln wird. Vielleicht (...und IMHO wahrscheinlich) redet da in einem Jahr keiner ein Wort mehr drüber. Die Wahrscheinlichkeit, dass man da aufs falsche Pferd setzt ist IMHO sehr hoch, weil C# einen zeitlichen Nachteil gegenüber Java hat und zuwenig neues bringt.
    Dies was du hier geschrieben hast in ein Beweis, das du dich mit .NET nicht richtig auseinander gesetzt hast. Vorteile:
    [list]* Einfachere Entwicklung von Anwendungen : Wie unter Visual Basic lassen sich GUI-Anwendungen schneller Entwickeln. Der Vorteil von .NET gegenüber VB ist, dass man über Interopservices Zugriff auf alle native Komponenten die auf dem System installiert hat. Der ganze Wirwar an Win32 Funktionen, sind jetzt übersichtlicher Struktoriert und .NET lässt sich einfacher benutzten als die MFC.

    Ja das stimmt wohl. Aber Vorteil von C# gegenüber Java ist dies nicht.
    Denn WinForms ist nicht plattformunabhängig.
    Java - SWT ist von der Geschwindigkeit erstaunlich gut.

    • Komponenten Entwicklung für COM, DCOM, ActiveX ( oder besser Windows DNA ) hat sich immens vereinfacht. D.H ich kann unter .NET auf COM-Komponenten zugreifen, aber auch mit .NET Komponenten anbieten die eine native Anwendungen über COM zugreifen kann. Nachteil ist vielleicht, das .NET installiert sein muß.

    Nachteil ist das du auf anderen Plattformen als Windows kein COM finden kannst.
    DCOM leistet auch nicht das was mit Enterprise Java Beans möglich ist.
    Ich habe gelesen das Zustansbehaftete verteilte Komponenten mit DCOM nicht
    möglich sind. Nicht umsonst setzen Firmen wie BEA, Oracle IBM auf EJB Container
    und nicht DCOM.
    Wenn ich hier falsch liegen soll bitte ich um aufklärung.

    • Ich kann meine Sprache frei wählen ( Ok, sie muß natürlich die CLR vollständig unterstützen )

    Es gibt ebenso verschiedene Sprachen die Java Bytecode erstellen.
    Es hat sich jedoch nicht durchgesetzt das diese genutzt werden.
    Was daran liegen kann das die Sprache Java wirklich wunderbar
    für ihr einsatzgebiet passt.

    Einfache XML-WebServices Entwicklung. Auch wenn ASP.NET noch allerhand Bugs hat sehe ich hier große Potenzial. Allerdings ist dies nicht mein spezialgebiet.

    Webservices lassen sich mit etwas Kenntnis in Java ebenso recht leicht entwickeln.
    Ich gebe zu das Visual Studio .net es dir so einfach machst das du
    nichtmal programmieren können muss um einen Webservice zu erstellen.
    Nur sehe ich hier das Einsatzgebiet von RAD nicht. Wenn ich einen Webservice
    entwickeln will dann sollte der Entwickler schon erfahren genug sein um auch
    so WSDL u. SOAP zu verstehen.

    • Die Administration von Komponenten ( jetzt Assemblies ) hat sich stark vereinfacht. Dadurch das sich eine Assembly sich selbst beschreibt, muss sie als private Assembly nicht mehr Registiert werden. Und mit Anwendung.exe.config kann man auch alle Unterverzeichnisse angeben die von der Anwendung benötigt wird.

    So stand das auch in .net Crashcourse MS-Press
    welches ich vor 1.5 ?? Jahren mal gekauft
    hatte.
    Musste schnell feststellen das dies kein Fachbuch
    sondern ein Werbebuch war und eigentlich
    die Hauptaufgabe hatte die "Vorteile" herauszuarbeiten.

    • Eine Anwendung hat weiterhin die .exe Ergänzung, also sie verhält sich wie eine normale native Anwendung.

    Auf windows.
    Geht mit Java ebenso, Wenn du software schreibst was hält dich davon ab eben für die 3 wichtigsten Plattformen (U|Li)n(u|i)x,Windows,MacOS eben scripts zu schreiben.
    MacOS kenn ich nicht. Aber den Aufruf zu automatisieren würde ich mich in Windows und Linux/Unix trauen durchzuführen.

    • Bessere Versionsverwaltung, wobei ich selber bestimmen kann ob ich eine starke oder eine schwache Versionsverwaltung benutze.
    • Man muß für primitive Typen keine Wrapper Klassen schreiben, usw.
    • Und halt der Rest was Java so kann.

    Das mit den Wrapper Klassen lasse ich wirklich gelten.
    Boxing wird das Marketingtechnisch bei .net gesehen und
    ist ne Tolle sache.

    Den Rest den Java kann seh ich nicht so. Es gibt eine menge
    was .net nicht zu verleisten mag im moment.

    [ Dieser Beitrag wurde am 21.01.2003 um 13:19 Uhr von HolyFly editiert. ]

    0
  • S

    Auf windows.
    Geht mit Java ebenso, Wenn du software schreibst was hält dich davon ab eben für die 3 wichtigsten Plattformen (U|Li)n(u|i)x,Windows,MacOS eben scripts zu schreiben.
    MacOS kenn ich nicht. Aber den Aufruf zu automatisieren würde ich mich in Windows und Linux/Unix trauen durchzuführen.

    Es ist nichtmal nötig für Windows nen Script zu schreiben. Es gibt einen echten Compiler, der dir eine Exe aus deinen Java Klassen erstellt.

    0
  • G

    Denn WinForms ist nicht plattformunabhängig.
    Java - SWT ist von der Geschwindigkeit erstaunlich gut.

    SWT ist AFAIK auch nicht plattformunabhängig. ...IMHO spielt Geschwindigkeit in diesem Bereich aber keine Rolle. Ich hatte noch nie Performance-Probleme mit Swing.

    0
  • ?

    Und warum ist dann nur als Beispiel der Borland JBuilder (und andere IDEs) sau lahm?

    0
  • G

    Original erstellt von <swing lamez>:
    Und warum ist dann nur als Beispiel der Borland JBuilder (und andere IDEs) sau lahm?

    Konnte ich so noch nicht feststellen. Der JBuilder hing bei mir früher manchmal ein paar Sekunden. ...Opera hängt bei mir manchmal ne halbe Minute und Opera hat nichts mit Swing zu tun.

    0
  • S

    Opera hängt ne halbe Minute?
    Mhhh - konnte ich bisher nicht feststellen.
    Momentan hab ich die 7 Beta 2

    0
  • H

    Als ich mal den JBuilder 4 mit keine Ahnung
    mehr welcher jre Runtime ausprobiert habe
    war JBuilder auch saulahm.
    Nun mit 1.4 und JBuilder 8 sehe ich dies auch
    nicht.
    Für die meisten ist Swing ganz einfach ziemlich
    ungewohnt.

    SWT ist vielleicht nicht "wirklich" Plattformunabhängig.
    Aber es äuft auf meinem Linux Rechner und Windows Notebook
    klasse.
    Soviel ich wiess ist auch MacOs kein Problem.

    0
  • S

    Also wenn du ohne RAD auskommst: http://www.javaeditor.de/ - der Editor ist nicht übel.

    Aber nano, vi und co tun es auch 😉

    0
  • ?

    thx für den tipp mit javaeditor SnorreDev 🙂 🙂 🙂 🙂 🙂 🙂 🕶

    0
Anmelden zum Antworten