Dynamische LINQ Verbindung

verwendetes Datenbanksystem: MS SQL Server 2005

Hallo,

ich möchte eine Anwendung programmieren, die benutzerabhängig Daten aus der jeweiligen Datenbank ausliest.
Verwenden möchte ich dazu LINQ.

Ich bin dabei zu überlegen, wie ich das am besten lösen kann. Ich habe bisher nur den O/R Designer (heißt doch so, oder?) benutzt. Aber dieser ist ja immer nur auf eine Datenbank beschränkt. Die Strukturen der Datenbanken sind immer gleich.

Mein Lösungsansatz wäre, jedes mal einen eigenen DataContext entsprechen der Userdatenbank zu erstellen. Das funktioniert dann aber nicht für die LinqDataSources. Ich habe auch keine Möglichkeit gefunden, diese an den selbst erstellen DataContext zu binden.

Vielleicht gibt es eine Möglichkeit die Datenbankquelle des im O/R Designer erstellten DataContext zu ändern!

Ich wäre für Lösungs- und Denkansätze dankbar!

hi,
was meinst du mit benutzerspezifischen daten?
die datenbank kann man beim dem o/r-mapper ohne weiteres wechseln, nur die struktur muss die gleiche sein. kann du vielleicht ein beispiel posten?

wenn man richtig dynamische abfragen mit linq machen möchte braucht man glaube ich noch eine erweiterung.
http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx

Hi,

danke für die schnelle Antwort.

Das soll nur heißen, dass ich jeder Benutzer eine eigene Datenbank hat.

Was möchtest du denn genau sehen?
Ich habe die Datenbanken per OR Designer integriert und initialisiere davon jeweils ein neues Objekt mit dem ich dann arbeite.

Die Struktur ist in jeder Datenbank gleich. Es würde mir also reichen, die Datenbankverbindung des DataContext Objektes zu ändern dafür zu ändern. Wie stelle ich das an?

welchen o/r mapper verwendest du denn?

ich hab aber noch nie gehört, dass man eine extra-datenbank erstellt für einen anderen nutzer. ist das wirklich notwendig? kannst du nicht z.B. mit einem "Schema" arbeiten
[Benutzername].[Tabellenname]. Vielleicht geht das auch noch einfacher.
wie hälst du denn die Struktur gleich? das ist eigentlich eine gefahrenquelle. ich kenn aber natürlich deinen anwendungsfall nicht.

vielleicht hilft dir das:
Trennung von Benutzer und Schema

Beim Entity Framework übergibt man einfach dem Konstruktor des Kontexts eine Verbindungszeichenfolge, und arbeitet dann bequem auf der Datenbank, die dort angegeben wurde...ich verstehe das Problem nicht so ganz. Dafür gibt es doch die ganzen Datenbank-Factoryklassen in .NET.

LaTino

/* connectionString kann bsp. eine der Connections in app.config sein, oder sonstwo stehen */

string connectionString; //anderswo gefüllt
string providerName; //kann man auch aus dem ConnectionString ermitteln, dafür gibt es wieder Klassen


DbConnection connection = DbProviderFactories.GetFactory(providerName).CreateConnection();
connection.ConnectionString = connectionString;

using(MyEntityContext context = new MyEntityContext(connection))
{
   Console.Write(context.Users.First().Name);
}

Wie gesagt, ist an sich kein großes Problem...

LaTino

ist das üblich mehrere datenbanken anzulesen?

Ja, wieso nicht. Wobei die Strukturen der Datenbanken durchaus unterschiedlich sein können. In EF lädt man dann halt andere mappings in den Kontext. Auf die Weise kriegst du ein und dasselbe Objekt aus komplett unterschiedlichen Tabellenstrukturen komplett verschiedener Datenbanken komplett verschiedener Datenbankhersteller.

LaTino

naja genau wegen dem andere mapping halt. da sollte es schon einen trifftigen grund geben warum man sowas benötigt.

Ich verstehe die Frage nicht so recht. Warum sollte man auf verschiedene Datenbanken zugreifen?
Na, weil die Daten in verschiedenen Datenbanken liegen, wieso sonst?

Stichwort SOA, verteilte Anwendungen, domänenübergreifende Applikationen.

LaTino

ich möchte eine Anwendung programmieren, die benutzerabhängig Daten aus der jeweiligen Datenbank ausliest.

ok. aber in diesem zusammenhang würde ich das nicht naheliegend finden. denn bei benutzerabhängigen daten sollten sich die strukturen normalerweise nicht unterscheiden.
vielleicht gibt es diesen fall auch, aber ich sehe ihn bisher nicht. wer soll denn diese struktur warten...

Warum sollte man die Strukturen warten? Nur die Mappings müssen ggf. angepasst werden. Die Strukturen der Datenbanken müssen doch gar nicht gleich sein, Hauptsache es gibt irgendwelche Felder, in die die relevanten Daten hineingeschrieben und aus denen sie gelesen werden.

Du hast vermutlich insofern recht, dass das Szenario von aerodur ein wenig nach schlechtem Design riecht. Andererseits sind eben auch Szenarien vorstellbar, wo das ganze einen Sinn ergibt 😃.

Wat weiß ich...sagen wir, es geht um eine zentrale Benutzerverwaltung verschiedener Applikationen - ein CMS, das seine Benutzer in einer MySql-Datenbank hält, und eine Buchhaltungssoftware, die ihre Benutzerdaten in einem SQLServer speichert. Wäre doch nicht so übel, wenn man mit ein und derselben Klasse der DAL-Schicht wahlweise auf die Benutzer des CMS oder der Buchhaltung zugreifen könnte.

Du verstehst?

LaTino

OK.
Ich habe mich vielleicht etwas missverständlich ausgedrückt. Es geht dabei nicht um einzelne Benutzer. Es geht vielmehr um ganze Firmen, die je eigene Datenbanken haben, deren Struktur sich aber gleicht, oder zumindest nur sehr wenig voneinander abweicht.

Ich bin in C# auch noch nicht der Crack, sondern noch in der Lernphase. Hab also noch nicht alles so drauf 😃

--------------> Back to topic <---------------

1. Das bedeutet also, ich erstelle eine dbml Datei, die mir die Objekte der DB Tabellen im Code zur Verfügung stellt.

2. Mir reicht eine dieser Dateien, da die Struktur ja gleich ist

3. Ich ändere, wie von LaTino gezeigt, nur die Connection, indem ich dem DataContext bei der Initialisierung die neue Connection übergebe

Soweit richtig verstanden?

Ich denke, soweit hast du das richtig erfasst. Ich kann für Linq To Sql (.dbml) nicht die Hand ins Feuer legen, weil ich nicht wirklich damit arbeite. Linq To Entities funktioniert jedenfalls genau so - und ich sehe keinen Grund, wieso Linq To Sql sich da groß anders verhalten sollte (würdest du mit ADO.NET arbeiten, wäre die Vorgehensweise ganz ähnlich, da ist also ein Muster erkennbar 😉 ).

Gruß,

LaTino

Puah! Super, Danke!

Das hilft mir dann schon mal ein ganzes Stück weiter. Ich probier's aus und geb dann mal ein Feedback, wie/ob es funktioniert hat.

Viele Grüße
aerodur

auf jeden fall war mir der vorteil des o/r-mappers im zusammenhang mit verschiedenen db-strukturen noch nicht so klar. das ist wohl ein wirklich enormer vorteil von mappern.

wenn ich nur an navision denke....dort sind so viele tabellen drin. da stürzt das management studio ab 😃 geht nur über systemtabellen... naja 😃 da ist auch was falsch gelaufen bei den jungs