Datenbankanwendungen richtig und Zeitgemäß programmieren

verwendetes Datenbanksystem: MS SQL 2008 R2

Hallo,

ich baue seit langem mal wieder eine Datenbankanwendung auf Basis C# .NET 4.5 und SQL 2008 R2.

Nun hab ich mich ein wenig durch das Visual Studio 2012 geklickt und festgestellt, es gibt einige Wege um Datenbank Anwendungen zu programmieren.

Version 1: Der alte Weg. SELECT, INSERT, UPDATE usw. manuell schreiben. Sehr aufwendig.

Version 2: DataSets zu nutzen.

Version 3: EntityFramework nutzen.
Nachteil: Sehr aufwendig für den Anfänger.

Prinzipiell würde ich zu Version 2 tendieren. Aber ist das denn richtig, dass ich trotzdem zwischendrin immer die SELECT Anweisungen schreiben muss um das DataSet wieder neu zu füllen?

Zudem habe ich nirgends wirklich eine verständliche Einführung gefunden.

Habt ihr da etwas? Oder welchen Weg würdet ihr empfehlen?

PS: Es ist eine relativ kleine Anwendung, welche aus maximal 10 Tabellen bestehen wird. Aber ich bin halt faul was das getippe angeht 😉

Für eine kleine Anwendung würde ich vermutlich mit ADO.NET selbst meine Selects schreiben.
Allerdings finde ich das für einen Anfänger im Gegensatz zum Entity Framework eher komplizierter.

Was findest du denn deiner Meinung nach am EF kompliziert zu verstehen?
Gerade der typisierte Zugriff über LINQ macht das ganze doch sehr einfach 😃

Edit: Ich habe vor langer Zeit mal einen Artikel über EF / SQLite und LINQ geschrieben:
Visual Studio 2010 (Express) – Linq 2 SQLite2Entities
Lies dir das mal durch, vll verstehst du es ja sogar 😃

Meine Meinung.

SELECT, INSERT, UPDATE usw. manuell schreiben. Sehr aufwendig.

Aber auch sehr flexibel. Das macht genau das was du willst.

Für einfachere Situationen ist ein DataSet natürlich komfortabel. Daten lesen, anzeigen, evtl. noch ändern und wieder abspeichern.
Wenns an mehrere Tabellen geht, wirds mit dem speichern schon komplexer.
Mit Frameworks oder sonstigen versteckten Dingen (z.B. was im DataSet alles passiert) kriegst du zwar schnell was hin, kommst aber vielleicht an die Grenze des machbaren.

Wenn ich bei einem Speichern-Ablauf 3 Tabellen in einer Transaktion füllen muss und dabei noch irgendwas wieder an die Anzeige zurückliefern, dann wird das selber programmiert ohne an DataSet oder sonst was zu denken. Irgendein Ablaufschritt erfordert dann doch alles selbst zu machen, da tu ich das lieber gleich als in eine Sackgasse zu laufen.
Außerdem will ich dann vor mir sehen was wie passiert, ohne die Hälfte der Logik irgendwo versteckt zu haben, selbst wenn ich wüsste dass irgendein Mechanismus das (vielleicht ansatzweise) kann.

SQL können ist auch heute noch kein Schaden. Als LINQ aufkam hab ich über Artikel gelächelt in denen stand "wird SQL ersetzen, endlich kein SQL mehr". Heute weiß ich warum 😃

@Chilic:
NIH-Syndrom ?

@brave_snoopy:
Das ist eine ähnlich sinnvolle Frage wie "Welches Auto soll ich benutzen um von A nach B zu kommen?".
Es kommt doch auf die Umstände an. Hast du 12 Tonnen Gepäck, fällt ein Porsche 911 raus.
Ist dazwischen Sahara, kommst du damit auch nicht weit ( der Cayenne ist da auch nix ).
Ist aber nur Autobahn dazwischen kannst du den auch nehmen.

Genau so ist es bei Datenbanken.
Hast du Massendaten zu verarbeiten, ist weder DataSet noch ORMapper sinnvoll, sondern nur die DB Sprache ( SQL/NoSQL).

Bei Programmen mit 5 Dialogen und 10 Tabellen machen DataSets Sinn.
Alles was da drüber an Dialog orientierten Programmen kommt, ist mit einem ORMapper einfacher zu warten.
Ob das EF sein muss, oder etwas anderes ist dann relativ egal.

Ich zitiere einfach mal Deinen Titel

Datenbankanwendungen richtig und Zeitgemäß programmieren

Wie wärs, wenn Du erst mal evaluierst, was für Daten Du zu speichern hast...?
Nicht alle Datenbanken arbeiten mit SELECT, INSERT und Update - und gerade bei Neuentwicklungen wird ofterkannt, dass die klassiche relationale Datenbank nicht nur Vorteile hat.

Im Prinzip sag ich hier das gleiche, wie FZelle.
Und danach kann man sich gedanken machen, wie man die DB anspricht.

Hast du Massendaten zu verarbeiten, ist weder DataSet noch ORMapper sinnvoll, sondern nur die DB Sprache ( SQL/NoSQL).

Das irritiert mich jetzt ein wenig. Sind moderne ORMapper wirklich so schlecht?

Ja.

Paar zahlen aus meinem Blog (das betrifft aber nicht nur das EF, sondern alle aktuellen ORM und auch quer durch alle Sprachen):
Vergleich:
MongoDB mit C# Driver (1) | SQL Server 2012 (2) | Entity Framework 5 (SQL 2012) (3)

Insert 1.000 Einträge 0,07 Sek. (1) | 35,6 Sek. (2) | 102 Sek. (3)
Insert 100.000 Einträge 4,1 Sek. (1) | 3 Min. 56 Sek. (2) | 23 Min. 12 Sek. (3)
Insert 10.000.000 Einträge 41,4 Sek. (1) | 26 Min. 37 Sek. (2) | 7 Std. 9 Min. 41 Sek. (3)

Klare Ansage. Das gibt mir jetzt zu denken, da ich für ein größeres Projekt mit vielen Datensätzen (10 Mio+) das Entity Framework einsetzten will.

Das EF punktet durch Features; nicht durch Performance.
Das liegt aber eben an der Art und Weise, wie es an die Typen kommt, die Relationen bildet und jeweiligen Entities serialisiert.
Zudem: sobald auch nur eine NavigationProperty geladen wird, geht die Performance dermaßen in die Knie, dass es negativ spürbar ist.

Aber: bei lokalen Anwendungen bzw. innerhalb eines (kleinen) Unternehmens ist das jetzt alles nicht soooo tragisch.
Im Web - mit >5000 Zugriffen / Sekunde -, wo dann auch noch andere Themen (horizontale Skalierung, Rapid Devlopment, BigData...) aufkommen, sieht das alles halt etwas anders aus. Also man muss jetzt seine lokale Anwendung zur Musik-Ordnung nich umschreiben. Das wäre Quatsch.

@Alf Ator:
Du musst da aber unterscheiden zwischen Massendaten Bestand oder Massendaten Verarbeitung.

Wenn Du 10 Mio Datensätze hast und diese ständig komplett bearbeiten oder umschaufeln musst, ist ein ORM nicht der richtige Weg, denn der muss ja jeden Datensatz von der DB zum Programm transportieren, dann in die Klasse "wandeln" und dann in eine Liste im Speicher packen ( oder per iterator ).
Das kostet natürlich alles zeit und speicher.
Wenn du aber immer nur ein paar hundert oder tausend Datensätze einliest, dann ist es egal.

Also Dialogbetrieb ist bei Sql Servern ( egal welcher Marke ) recht performant, brauchst du ständig den Zugriff auf Mio von Datensätze oder Berechnungen daraus musst du Dich mit der jeweiligen Datenbanksprache auseinandersetzen.

NIH-Syndrom ?

Nö, nur Rundumblick, der für den gefragten zeitgemäßen Umgang mit einer Technologie kein Fehler ist 😉

Ich hab nichts gegen Frameworks, aber neben dem vielen wofür sie geeignet sind sind sie für manche Dinge Overkill und für andere sind sie eben zu sehr Standard. Das sollte man schon auch erkennen statt einfach mit dem allerneuesten auf sein Problem loszuballern.

Vielleicht ists wirklich sehr old school, aber komplexere Sachverhalte tippe ich lieber und schneller in selbstgemachtem SQL runter als sie einem Framework zu erzählen.

Hallo Snoopy,

Prinzipiell würde ich zu Version 2 tendieren. Aber ist das denn richtig, dass ich trotzdem zwischendrin immer die SELECT Anweisungen schreiben muss um das DataSet wieder neu zu füllen?
Zudem habe ich nirgends wirklich eine verständliche Einführung gefunden.

Eine kurze Einführung gibt es hier :

http://www.seven-c.de/files/datenbankenhowto.htm

Bei so großen Datenmengen würde ich mit DataReader lesen und mit DataSet oder Update-SQL-Kommandos ändern.

Grüße Bernd