C# SQL Zugriff auf Instanzebene?

[roker002]

Ich habe eine Frage... mir wurde gesagt, dass es sowas wie Entity SQL gibt. Also man hat den Zugriff auf die Datenbank durch die Instanz selbst und nicht durch Tranc-SQL. Es geschieht alles Dynamisch, d.h. die Datenbankrelation wird auf eine Dynamische Klasse übertragen (oder sowas ähnliches). Es ist aber (glaube ich) nicht LINQ to SQL...

Hab immer mit Tranc-SQL gearbeitet, was den Nachteil hat, das man immer query schreiben muss. Mit der Instanzierung muss man keine Queries mehr schreiben.


Kennt jemand das?

 

[Velines]

Eventuell meinst Du NHibernate:

NHibernate is a port of Hibernate Core for Java to the .NET Framework. It handles persisting plain .NET objects to and from an underlying relational database.

 

[2fastHunter]

Ich glaube Du suchst einen OR-Mapper. Da kann ich Dir für das .Net-Framework NHibernate oder OPF3 http://www.opf3.com/Opf3/ empfehlen. Beide kosten nix und funktionieren ähnlich. Damit kann man auf Entity-Ebene arbeiten oder SQL-Statemenst direkt absetzen. Viel Spaß beim Probieren

 

[toeffi]

Jop kenne ich, und das heißt für .NET ADO Entity Framework. Man sogar direkt Klassen dafür anlegen und sich die Tabellen wie in einem Designer zusammen ziehen und bekommt ein komplettes OR hinten raus.

 

[Cepheus77]

Du sprichts von OR Mappern. Da würde ich entweder zu nHibernate (Open Source) oder zum Microsoft Entity Framework (Linq-To-Entities) raten. Linq-To-Sql (ebenfalls von MS) ist tot und wird nicht mehr weiterentwickelt.

 

[toeffi]

Tot, heißt nicht das man es nich verwenden sollte Es kommt auf den Anwendungsfall an, wenn man nur minimalen SQL Zugriff brauch, würde ich eh von jeglichen Mappern abraten, bei etwas größeren Sachen ist LINQ-To-SQL schon geeignet da muss man nicht unbedingt die ADO.NET Keule rausholen, aber bei richtig Dicken dingern ist ADO.NET natürlich angebracht, genauso wie NHibernate.

 

[roker002]

@toeffi

was ist groß für dich? Größe ist relativ. Bis jetzt habe ich nach jeden Sql Befehl die Verbindung wieder geschlossen. Also ist Trans-SQL doch schneller als Instanzierung?

Moment, ich sehe da kein Unterschied zwischen ADO.NET und Trans-SQL

 

[Velines]

Gibts eigentlich auch was "leichtes", was mit Oracle (und damit ODP.NET) kompatibel wäre? NHibernate funktioniert, klar, aber das ist ja manchmal etwas Overkill.

 

[toeffi]

@roker. Also groß ist für mich wenns so über 10-15 Tabellen geht und man wirklich ununterbrochen auf die Datenbank zugreifen muss, wenn man aber nur so sporadisch mal was nachgucken muss ist ADO.NET zu dick.

@Velines: Soweit ich weiß gibts für .NET auch für Oracle dementsprechende Provider, OleDb oder sowas in der Art ist das doch, bin mir aber grad nich 100% sicher.

 

[roker002]

Wie sieht es aus mit Joins bei Nhibernate? Ich habe mal den Tutorial reingeschaut... sieht echt übel aus!

für alle Datenbanken was .NET unterstützt.... hier

 

[toeffi]

Naja die Joins machst du in ADO.NET über die LINQ Syntax und fertig.
Ja danke für die ConnectionsStrings.

 

[Cepheus77]

Achtung: hier werden Begriffe falsch durcheinander geworfen. ADO.NET ist die Datanbankzugriffstechnologie von MS. Damit kann man SQL connections öffnen, SQL Kommandos absetzen, Transaktionen öffnen, ... . Ein OR Mapper, egal welcher, setzt auf ADO.NET auf.

Das Entity Framework von MS ist auf jeden Fall Linq-To-Sql vorzuziehen, allerding nur die neue Version, kam mit .net 4.0. Ist auch für kleine Applikationen eine feine Sache. Um die Joins muss man sich nicht kümmern, das macht der Mapper.

Hier noch ein netter Blog Eintrag zum EF.