Ich hab das Buch "Einstieg in C# mit Visual Studio 2017" Daheim. In dem Werk geht es eigentlich nur um Codierung im Zusammenhang mit Windows Forms. Hier versuch ich einfach mal die Aufgaben alle (bis auf die zu leichten) in VB.NET zu programmieren.

Sollte ich denn den Arbeitgeber Fragen was genau ich in Zusammenhang mit VB.NET erarbeiten soll?

Bearbeitet 21. März 20196 j von DieMstar

vor 3 Minuten schrieb DieMstar:

Mir is nur wichtig das ich den Erwartungen entsprechen kann. Ich möchte ungern dauernd Fragen müssen oder am ersten Tag 7 Stunden für eine Datenbankanbindung in VB brauchen ?

Da wirst du sowieso nicht drumherumkommen.

Kann ja auch sein, dass sie einen O/R-Mapper verwenden, wie z.B. Entity Framework. Es ist für mich sowieso erstaunlich, wie viele Firmen heutzutage immer noch mit stumpfen SQL-Abfragen direkt auf die Datenbank gehen und daraus immer manuell selbst die Datenobjekte erzeugen, anstatt ein O/R-Mapper zu verwenden.

vor 5 Minuten schrieb Whiz-zarD:

Da wirst du sowieso nicht drumherumkommen.

Kann ja auch sein, dass sie einen O/R-Mapper verwenden, wie z.B. Entity Framework. Es ist für mich sowieso erstaunlich, wie viele Firmen heutzutage immer noch mit stumpfen SQL-Abfragen direkt auf die Datenbank gehen und daraus immer manuell selbst die Datenobjekte erzeugen, anstatt ein O/R-Mapper zu verwenden.

Auf meine Frage ob wir das Entity Framework benutzen hieß es, das ein älteres eigenes Framework im Einsatz ist. Welches wurde nicht genannt. kann mir dann auch nich vorstellen das es Hibernate wäre ?

Bearbeitet 21. März 20196 j von DieMstar

Dann musst du eh fragen. Aus Erfahrung sind solche Frameworks eh nicht dokumentiert und du musst dich selbst dort einarbeiten.

Bearbeitet 21. März 20196 j von Whiz-zarD

Nur mal zum Thema "Taschenrechner", weil's gerade aktuell ist. Microsoft hat vor kurzem den Windows-Taschenrechner als Open Source veröffentlicht: https://github.com/Microsoft/calculator

Ist natürlich mehr als ein "simpler" Taschenrechner. Aber wenn man sich da mal durchwühlt (ist wirklich nicht der simpelste Code), dann bekommt man mal eine Vorstellung davon, wie komplex das Problem eigentlich ist. (Was man da nebenbei ganz schön sieht ist die Trennung von Oberfläche und Logik.)

vor 17 Stunden schrieb Whiz-zarD:

Es ist für mich sowieso erstaunlich, wie viele Firmen heutzutage immer noch mit stumpfen SQL-Abfragen direkt auf die Datenbank gehen und daraus immer manuell selbst die Datenobjekte erzeugen, anstatt ein O/R-Mapper zu verwenden. 

Zumal es hier auch leichtgewichtige Lösungen wie Dapper gibt.

Wenn man mit Stored Procedures arbeitet bekommt man relativ schlanken Code.

vor einer Stunde schrieb Gooose:

Wenn man mit Stored Procedures arbeitet bekommt man relativ schlanken Code.

Sehe ich persönlich nicht so. Stored Procedures haben zwar den Vorteil, dass sie von der Datenbank auf Fehler überprüft werden aber man verschiebt nur die Logik, die sonst im Programmcode steht, in die Datenbank und das kann je nach Szenario Probleme bereiten. Wenn man anfängt, für jeden Kleinkram eine Stored Procedure zu schreiben, müllt man die Datenbank damit zu. Zumal die Verwaltung von Stored Procedures eh sehr schlecht ist. Ein anderes Problem ist, wenn die Stored Procedure mehrere Werte oder sogar ganze Tabellen zurückliefern soll. Tabellen als Rückgabewert ist z.B. in MySQL sowieso nicht möglich. Bei Oracle gibt es die sog. Tablefunctions aber die haben einen sehr großen Programmier-Overhead und lassen sich auch nicht debuggen. 

 

vor 24 Minuten schrieb Whiz-zarD:

nur die Logik, die sonst im Programmcode steht, in die Datenbank

Das kann man drehen wie man will größere Algorithmen werden in Sachen Performance gegenüber einer Storen Procedure immer den kürzeren ziehen imo.

Man muss das immer relativ betrachten. Programmcode kann man in der Regel verständlicher schreiben, als Stored Procedures, weil sie nun mal sehr viele Restriktionen haben. Die Frage ist: "Was ist wichtiger? Lesbarer Code oder bessere Performance?" Ist es wirklich wichtig, dass der Nutzer schnellstmöglich eine Antwort erhält? Oder kann er auch mal ein paar Sekunden warten?

An der Software, an der ich arbeite, wurden ebenfalls sehr viele Kennzahlberechnungen als Stored Procedure abgelegt. Die Folge ist, dass sie sehr komplex sind und sie kaum einer noch versteht. Das Debugging ist extrem schwierig. Es wurden Tablefunctions verwendet, die wie gesagt, nicht mit dem Debugger debugged werden können. Da ist man wieder dabei, nach alter Väter Sitte, Ausgaben auf der Konsole zu machen, um zu sehen, was passiert. 

Ich bin der Meinung, man sollte erst mal mit einem lesbaren und verständlichen Code anfangen und erst dann, wenn die Performance zwickt, sollte man sich über die Performance unterhalten. 

Sicherlich sollte man nicht anfangen zu optimieren, bevor überhaupt ein Bottleneck zu erkennen ist. Ich kenne auch Prozeduren, die sich über hunderte Zeilen erstrecken, und quasi nur von außen oder "raise info" testbar sind. Ich denke, die Mischung machts. Man kann ja erst mal ohne anfangen, und wenn man beispielsweise merkt, das bestimmte Aktionen zu viele Roundtrips zur Datenbank übernehmen, kann man ja eingreifen. Andere Anwendungsfälle kommen mit Caching bestens zu recht, wenn die "teure" Datenbankaktion nur nach einer Cacheinvalidierung geschieht.

Was ich eigentlich aufzeigen wollte ist, dass man mit MicroORMs auch zu guten Ergebnissen kommen kann. Es gibt einfach weniger bewegliche Teile.