Wohin geht der Trend?

29/06/2009 - 12:29 von Frank Bergmann | Report spam
Hallo,

was ist der beste Weg einen Datenbank anzusprechen da es je einige neue Wege
gibt.
Wie z.B. Linq to SQL, ADO.Net to Entity oder direct mit Connectionstring.
Auf welchen Weg sollte man sich konzentrieren?
Dann Lese ich auch immer wieder das Store Procedures in Verbindung mit Linq
to SQL besser wàre.
Das bedeutet ja die komplette Datensicht im SQL Server bereitstellen.


Gruß
Frank Bergmann
 

Lesen sie die antworten

#1 Elmar Boye
30/06/2009 - 10:08 | Warnen spam
Hallo Frank,

Frank Bergmann schrieb:
was ist der beste Weg einen Datenbank anzusprechen da es je einige neue Wege
gibt.



Einen "besten" Weg gibt es IMO nicht.
Viele Wege führen nach Rom, wie man so schön sagt,
und je nach Anforderungen kann der eine oder andere
günstiger, kürzer oder weniger steinig sein.

Wie z.B. Linq to SQL, ADO.Net to Entity oder direct mit Connectionstring.



"Neu" sind Linq2Sql bzw. das Entity Framework nur bei Microsoft.
Das Konzept O/R-Mapping ist àlter und in anderen Frameworks
wie Java lange verbreitet und bereits bei .NET 1.0 auch von
Drittherstellern verbreitet worden.
Einer der bekanntesten Open Source Projekte NHibernate
http://www.hibernate.org/343.html
ist ein Port aus dem Java Bereich.

Zeitweise (so um 2005 rum) gab es regelrechte Flut davon,
worauf auch Microsoft sich um das Thema "gekümmert" hat

Auf welchen Weg sollte man sich konzentrieren?



Ich würde derzeit keinen der Microsoft ORMs wirklich empfehlen.

Linq2Sql ist nach derzeitigem Stand (.NET 3.5) zwar einiges
besser, nur wird sich dort vermutlich nicht mehr viel rühren.

Denn ursprünglich vom SQL Server Team entwickelt ist es in
die Hànde es EF Teams übergegangen:
http://blogs.msdn.com/adonet/archiv...admap.aspx
und eine Weiterentwicklung (abseits einer Wartung) zweier Produkte
durch ein Team ist eher unwahrscheinlich, exemplarischer Kommentar dazu
http://codebetter.com/blogs/david.h...-home.aspx

Was das Entity Framwork angeht:
In dem gleichen Blog (http://blogs.msdn.com/adonet/default.aspx)
findest Du in den neueren Beitràgen die derzeitigen Schwàchen
des Entity Frameworks dokumentiert.

Denn trotz ziemlich langer Schwangerschaft war die Geburt eher
eine Frühgeburt im Vergleich zu anderen Produkten ;-()

Mit .NET 4.0 ist Besserung gelobt worden, wie dort zu lesen.
Nur Beta ist Beta, und wie sich das am Ende gestaltet,
mag (mal wieder) anders aussehen.

Dann Lese ich auch immer wieder das Store Procedures in
Verbindung mit Linq to SQL besser wàre.



Die Argumentation kommt üblicherweise von Datenbank Administratoren,
denen hàufig graust, welcher Code ein ORM (unabhàngig welcher Couleur)
u. U. produziert. Die hàtte gerne mehr Einfluß darauf und möchten
dort ggf. optimieren.

Was aber nicht einmal die halbe Miete ist.
Denn auch bei einem ORM muß man die Mechanismen verstehen,
welche Anweisung, welche Abfragen an die Datenbank generiert.

Dabei kann man durch die höhere Abstraktion, die Linq bedeutet,
zwar schneller Code im Frontend schreiben, aber ebenso schnell
schlechtes SQL am anderen Ende erzeugen.

Der Einsatz von Prozeduren wiederum ist nicht perse besser,
denn er bedeutet schnell den Verlust der Flexibilitàt von
dynamischen Anweisungen.

Das bedeutet ja die komplette Datensicht im SQL Server bereitstellen.



Schon mal was vom SQL Server Profiler gehört?
Welches SQL Du an einen SQL Server sendest, làßt sich
nicht geheim halten. Das ist also kein Argument.

Zusammenfassend: Auch wenn sich oben manches von mir negativ liest,
so bieten ORM grundsàtzlich viele Vorteile, da sie die Verbindung
zur Datenbank vereinfachen und flexibler gestalten können.

Einsteigen solltest Du aber eher mit einem kleineren Dingen
als gleich eine langlaufendes Projekt mit hoher Wartungsdichte
damit anzufangen.
Besonders wenn Du die Microsoft Implementationen verwenden möchtest,
denn da wird (und muß) sich einiges tun, wo Du am Ende den Weg
mitgehen müßtest.

Pragmatischer, wenn auch noch weniger Linq, wàren ein ORM
wie NHibernate. Die sind derzeit deutlich ausgereifter
und es gibt Tools wie NHProf.

Abseits von den Datenbankzugriffen lohnt es sich aber generell
mit den Konzepten von Linq zu befassen, denn damit kann auch
das tàgliche Programmieren leichter von der Hand gehen.
Und das dort gelernte auf anderes (nicht nur ORM) übertragen
werden. Siehe
http://msdn.microsoft.com/de-de/lib...97919.aspx
"Allgemeines LINQ-Programmierhandbuch"
und http://msdn.microsoft.com/de-de/lib...97919.aspx
"LINQ to Objects" und immer so weiter...

Gruß Elmar

Less Spam Better enjoyable experience
Visit : news://spacesst.com

Ähnliche fragen