Umstieg Java/Oracle => C#/MSSQL

[Gast2]

Hi,

Als großer Fan von Java und der Oracle DB schmerzt es mich jetzt sehr das ich mich für den neuen Job auf einen Technologiewechsel gefasst machen muss. Ich habe bisher schon ein wenig begonnen mich mit C# auseinder zusetzen und komme soweit ganz gut klar. Ist ja schon recht ähnlich und die Erfahrungen die ich während der 6 Jahre die ich in Java programmiert habe scheinen sich relativ einfach auf C# übertragen zu lassen. Allerdigns fallen mir immer wieder Kleinigkeiten auf wie z.B. Call by Reference durch [c]ref[/c] Keywords oder das alle das [c]string[/c] Keyword statt der Klasse [c]String[/c] nutzen. Das ist alles etwas merkwürdig.

Gleiches gilt für die DB. Ich hab sehr lange mit Oracle 10g R2 und 11g R2 gearbeitet, viel in PL/SQL programmiert und mich an die Oracle JOIN Syntax usw gewöhnt. Mit TSQL und dem MSSQL SQL Dialekt gerade ich deswegen immer wieder aneinander. Nicht wildes aber halt wie in Java <=> C# Kleinigkeiten.

Hat einer ein paar gutes weblinks oder auch Bücher parat für einen Umstieg? Also ich brauche keine "Jetzt lerne ich programmieren mit C#"-Schinken oder "Datenbankabfragen mit ANSI-SQL" sondern wirklich Literatur oder links für den fortgeschrittenen Programmierer der einfach nur die Plattformen wechseln muss/möchte.

Any Ideas?

 

[Cage Hunter]

Ich habe zwar keine Ideen, Du hast jedoch mein Beileid...Allen meines Bekanntenkreises ist genau dieser Umstieg auch "sehr schwer" gefallen, besonders die Syntax von MSSQL soll ja richtig viel Spass machen wenn man an MySQL o.Ä. gewöhnt ist...Ich werde heute mal nachfragen, ob meine Kollegen da ein schönes Buch kennen

 

[Gast2]

das alle das [c]string[/c] Keyword statt der Klasse [c]String[/c] nutzen.

macht aber keinen Unterschied - kannst beides benutzen ... der Compiler macht da eh String draus

ansonsten -> myCSharp.de - DIE C# und .NET Community | Diskussionsforum

 

[Guybrush Threepwood]

@fassy: Kannst Du Literatur für den Umstieg empfehlen. Kennst Du Visual C# 2010? Ich möchte meine Programmierkenntnisse etwas erweiteren und neben Java (8 Jahre Programmiererfahrung, ebenfalls Java-Fan) C# lernen.

 

[Gast2]

@fassy: Kannst Du Literatur für den Umstieg empfehlen.

Ja, genau das such ich ja auch

Kennst Du Visual C# 2010?

Ja, das "Buch" kenne ich. Ist als Referenz durchaus brauchbar - ebenso wie die Insel, allerdings mir zu "gehaltvoll" als Umsteigerlektüre. Ich brauche keine Syntaxerklärungen, was Exceptions sind usw - sondern eher eine Übersicht der Unterschiede der Sprachkonzepte und der .NET Plattform.

Ich denke man kann sich wohl aus vielen Lehrbüchern wie auch dem so das alles zusammen suchen. Aber das muss doch schon mal jemand gemacht haben?

Ich habe zwar keine Ideen, Du hast jedoch mein Beileid [...] Ich werde heute mal nachfragen, ob meine Kollegen da ein schönes Buch kennen

Wäre nett wenn du mal nachfragst. Ich denke mal ich werd damit schon klar kommen. Zumal ich jetzt auch nicht mehr als Entwickler eingestellt bin sondern eine Customer Consulting/Field Support/Training Position habe und nur noch realtiv wenig selber programmieren werde.

 

[Gast2]

So, ich hab jetzt die ersten paar Wochen rum und kann mal meinen Eindruck schildern.

An für sich unterscheiden sich die Sprachen wirklich recht wenig. Ich hatte bisher nur sehr selten mal ein "WTF?" Erlebnis. Man kann das gesammte Software-Engineering Wissen (Pattern und Co) 1:1 auch weiterverwenden.

Interessante Unterschiede die sich mir bisher aufgetan haben:
=> Properties und Accessoren anstatt Getter/Setter Methoden
Anfangs war ich recht verwirrt warum denn alle C#ler mit public Fields arbeiten und die Kapsulung der OOP brechen. Bis sich mir dann irgendwann das Konzept der Properties auftat, mehr dazu hier:
Using Properties (C# Programming Guide) und Auto-Implemented Properties (C# Programming Guide)
Spart eine Menge Code und wenn man sich dran gewöhnt hat gar nicht mal ein schlechtes Konzept.

=> HashMaps aka Dictionary werfen Exceptions statt null zurück zu geben
Oh ja, das nervt. Wenn man aus einem Dictionary einen Key anfragt wozu es keinen Wert gibt fliegt eine Exception. Daran musst ich mich erstmal gewöhnen, schlimmer noch der nächste Punkt

=> Exceptions sind alle unchecked
Man wieß NIE wo eine Exception auftreten könnte das es keine [c]throws Exception[/c] in den Methoden Signaturen gibt. Also blubbert einem wenn man sich nicht gut mit der API auskennt schnell mal eine Exception tief aus dem Core herauf. Nicht sehr schön...

=> OUT Variablen
Da sind sie wieder, die guten alten OUT Variablen. Ich hasse sie eigentlich in allen mir bekannten Sprachen wo sie verwendet werden - und jetzt hab ich sie wieder an Board. Na egal, gibt schlimmeres und man kann versuchen sie weitgehend zu umschiffen.

Und last but not least: Crappy NamingConvention
Eigentlich beginnt alles mit einem Großbuchstaben, Klassen, Methoden, Accessoren, Properties... *schüttel*

Aber das war es eigentlich auch was mir so auf dern ersten Blick auffällt. Also eigentlich erschreckend wenig.

Guter link für Umsteiger oder an alle die mal in C# aus Java Perspektive schnuppern wollen: C# From a Java Developer's Perspective

 

[eRaaaa]

=> HashMaps aka Dictionary werfen Exceptions statt null zurück zu geben
Oh ja, das nervt. Wenn man aus einem Dictionary einen Key anfragt wozu es keinen Wert gibt fliegt eine Exception. Daran musst ich mich erstmal gewöhnen, schlimmer noch der nächste Punkt

Hm, dafür gibt es ja anscheinend "TryGetValue". (Dictionary(TKey, TValue).TryGetValue-Methode (System.Collections.Generic))

 

[fastjack]

Wenn von einer beliebigen DB zu MSSQL wechselt, dann ist das kein Umstieg, sondern ein Abstieg. Mein Beileid! Wenns ein neuer Arbeitgeber ist, der MSQQL schon lange benutzt, dann okay, aber wenn Ihr in der Firma nach MSSQL wechselt, würde ich mal die ganzen schlechten Seiten betonen, u.a. fehlende Replikation, "variable" Querylaufzeiten (für ein und dieselben Queries), MemoryLeaks, Vooles Laden der Tabellen in den Serverspeicher, selbst bei top 1 und und und.
Junge, Du bist verloren....

 

[Gast2]

Du scheinst das die Lizenzpolitik von Microsoft etwas misszuverstehen ... viele Dinge werden nur mit einer Anbindung an MSSQL augeliefert - WinCC / iFix und was weis ich noch für Automatisierung ... iFix verwendet zwar (offiziell) ODBC, läßt sich aber keinen MySQL ODBC-Treiber unterschieben ... manchmal hast Du keine andere Wahl

@fassy: vieles was Du angesprochen hast sind nur Ausreden der Gewohnheit ... ich benutze beide Sprachen und mir ist es egal

 

[fastjack]

Ich verstehe fassy. C# ist doch keine Sprache! Das ist irgendein M$-Teil, das alles erlaubt, aber alles ein wenig anders macht, damit sich auch wirklich jeder "wohlfühlen" kann. Was fürn Schmarrn. Das fängt damit an, das Du String schreiben kannst, wie Du willst, groß oder klein, alles Latte. Mit Integer natürlich genauso. Und dann gibt es ja noch den VB-Integer, der wird ein bissel anders geschrieben und hat glaube ich auch noch einen andere Wertebereich. Was fürn sh*t. Dann geht es weiter mit Operatoren-Überladungen. Ja, wenn ich an einem C#-Projekt arbeite, überlade ich regelmäßig - mit + und + mit -. Bis die anderen merken, was abgeht, sind schon viele Stunde verbrannt in der M$-Hölle. Die Aufzählung, die ich mit C#-Ungereimtheiten gemacht habe, geht gegen unendlich. Wenn es um Webservices und deren Anbindung an andere Sprachen geht (C#-Java, Java-C#) als Beispiel, wirds richtig spannend, da M$ hier alles nach seinen eigenen Standards und mit der super-veralteten xmlws.dll (oder so ähnlich) von VB macht. 1A mit Klasse! Großes "pfui-i-bah-tatta-mit-pippi" würden meine Kleinen sagen! Und Leute, mal ganz erhlich, daß hat sich Billy auch gedacht, als er die erste Master von C# in Druck gegeben hat (er lacht noch heute hämisch).

P.S.: ich verstehe die Lizenzpolitik von M$ auch nicht...

 

[Gast2]

Ich verstehe fassy. C# ist doch keine Sprache!

Nö, eigentlich verstehst du mich eher nicht . Was ich eigentlich mit meinem Posting sagen wollte ist: Der Umstieg fällt mir recht leicht weil gar nicht soviel anders ist. Wie mogel schon sagte - eher eine Frage der Gewohnheit.

Klar hat C# einige Ecken - aber nicht mehr oder weniger als Java meiner Ansicht nach.

Wenn von einer beliebigen DB zu MSSQL wechselt, dann ist das kein Umstieg, sondern ein Abstieg. Mein Beileid! Wenns ein neuer Arbeitgeber ist, der MSQQL schon lange benutzt, dann okay,

Da sind wir uns einig. Mit MSSQL werd ich nicht warm und wünsche mir jeden Tag eine 10g oder 11g, mit DataGuard, Shareplex, Toad, SQLNavigator usw zurück. Aber MSSQL ist hier (neue Firma) halt schon lange etabliert.

Hm, dafür gibt es ja anscheinend "TryGetValue"

Ja, kenn ich. Ist halt entgegen der "Gewohnheit" über den Key direkt zuzugreifen. So muss man sich immer auch wieder mit der out Variablen rumschlagen. Ich hab mir allerdings einen kleinen Wrapper gebaut der ein Get(string key) implementiert. Mag man nicht schön finden, aber mir hilft es

@fassy: vieles was Du angesprochen hast sind nur Ausreden der Gewohnheit ... ich benutze beide Sprachen und mir ist es egal

Richtig, sehe ich genauso. Wie gesagt die Properties sind sogar eine Bereicherung.

Das Einzige was aus meiner Sicht wirklich ein Designschwachpunkt der Sprache ist, wäre das Exceptionhandling, bzw das die Exceptionsdeklarationen nicht schon zur Compiletime ausgewertet werden können.

 

[Gelöschtes Mitglied 6946]

Eines der (zum Glück wenigen) Probleme, das ich mit "C Gartenzaun" hatte, war der mitunter etwas seltsame Gültigkeitsbereich von Variablen. Wenn ich eine for-Schleife hatte und in deren Schleifenkörper eine Variable angelegt hatte, dann konnte ich diesen Namen hinter der Schleife (also außerhalb) nicht wiederverwenden, weil es diese schon gab. Gleichzeitig konnte ich aber auf diese Variable nicht zugreifen, da es ja sein konnte, dass die Schleife 0 mal durchlaufen wird und sie somit nicht initialisiert war. Ist dir sowas auch schonmal untergekommen oder war das evtl. ein Problem mit VS oder so?

 

[fastjack]

Das Problem (Feature) hatten wir auch. Noch so eine Ungereimtheit.

 

[Gast2]

Hab ich grade mal ausprobiert - sehr strange indeed:

for(int i = 0; i < 5; i++){
  Console.Out.WriteLine(i);
}
int i = 0; // compilefehler

Allerdings ist mir das bisher noch nicht einmal so untergekommen da mein Code meist eh so strukturiert ist das es keine gleichen Variablennamen in Schleifen und ausserhalb gibt. Wenn soetwas vorkommt würd ich wahrscheinlich eher die Schleife extrahieren und in eine eigene Methode packen.

Sonst ist mir bisher mit dem Scope nichts weiter aufgefallen. Hab jetzt in 2 Wochen gut 5000 loc produziert und kaum eine Methode ist länger als 5 - 10 Zeilen, also ist das Riskio recht gering das ich da auf solche Probleme stoße