Ich habe hin und her geschaut, aber anscheinend konnte ich nicht erreichen, was ich brauche. Es tut mir leid, wenn das in letzter Zeit beantwortet wurde. Eine Weiterleitung zur Diskussion wird mir gut tun.
Dies ist das Szenario. Ich wurde angewiesen, von Microsoft Visual Foxpro (MS zieht Unterstützung zurückkommen 2015) zu .Net C # von meinem Chef. Um eine gute Grundlage zu schaffen und die Best Practices zu übernehmen, habe ich beschlossen, zuerst zu lernen, einschlägige Informationen zusammenzustellen und dann mit dem Codieren zu beginnen. Dies ist das zweite Jahr.
Wir sind eine Bürogesellschaft, die Outsourcing-Dienstleistungen für die Lohnbuchhaltung an über 50 Kunden anbietet. Jeder Client hat derzeit eine eigene Datenbank. Die Datenbanken haben Tabellen mit völlig identischen Strukturen.
Ich bin ein Neuling. Völlig neu für .net Welt.
Ich hatte mit Roh-SQL begonnen, indem ich Datenblätter und Datenleser benutzte, aber in meiner Recherche bekam ich einige Diskussionen, die das entmutigten. Viele waren der Ansicht, dass der Entity Framework diesen Zweck erfüllen sollte. Aber man darf Ansätze insbesondere bei komplexen Abfragen mischen.
Kann mir jemand auf etwas "gutes Lesen" hinweisen, wo ich Entity Framework mit über 50 identischen Datenbanken implementieren kann. Jede Datenbank ist völlig unabhängig und hat nichts mit anderen zu tun. Wenn sich der Benutzer anmeldet, wählt er den Client aus, für den die Abrechnung abgewickelt werden soll. Dann zeigt EF auf diese Datenbank.
EF benötigt zwei verschiedene Informationen, um mit Daten aus einer Datenbank zu arbeiten:
1) Das Datenbankschema: Dieses ist als kompilierter Code in Ihrer Anwendung enthalten und kann normalerweise nicht zur Laufzeit geändert werden.
2) Die Verbindungszeichenfolge: Diese wird zur Laufzeit bereitgestellt, normalerweise aus einer Konfigurationsdatei.
In Ihrem Fall haben alle Datenbanken das gleiche Schema, so dass Sie nur eine Datenbank modellieren können und sie für alle anderen funktioniert.
Das Stück, das Sie ändern möchten, ist die Verbindungszeichenfolge. Dies teilt EF mit, wie die Datenbank zu finden ist und kann zur Laufzeit bereitgestellt werden.
Es gibt eine Überladung des Konstruktors DbContext , der eine Verbindungszeichenfolge als Parameter akzeptiert: MSDN: DbContext Constructor (String)
Und es gibt sogar Klassen im Framework, die helfen, Verbindungszeichenfolgen für Sie zu erstellen:
Es ist sehr einfach
Ich hatte,
%Vor%bereits in automatisch generierten Model.Context.cs des edmx-Ordners
Um in Runtime eine Verbindung zu mehreren Datenbanken herzustellen, habe ich einen anderen Konstruktor erstellt, der die Verbindungszeichenfolge als Parameter verwendet, wie unten in der gleichen Datei Model.Context.cs
%Vor%Ich habe jetzt eine andere Verbindungszeichenfolge in Web.Config hinzugefügt, zum Beispiel
%Vor% Wenn ich dann eine Verbindung zur Datenbank herstelle, rufe ich die Methode connetionString name als Parameter
Hrmmm Ich mag EF Code First wirklich, aber ich bin mir nicht sicher, ob es zu dem passt, was Sie tun. Wie oft ändert sich Ihr Schema?
Wenn sich das Schema etwas regelmäßig ändert, kann der Migrations-Teil von EF Code First Ihnen viel Zeit und Aufwand ersparen, da Sie häufig SQL-Skripte für Schema-Upgrades abschaffen können - Schemaänderungen werden mit dem Rest in Ihrem Quell-Repository gespeichert von deinem Code stattdessen. Du würdest hier anfangen:
Ich mag auch wirklich, wie einfach es ist, EF einzurichten, und wie einfach es ist, LINQ-Abfragen dagegen zu schreiben und genau die POCOs zurückzugeben, die ich aus der Datenbank erstellt habe.
Aber EF ist vielleicht nicht die beste Lösung.
Viele andere ORMs unterstützen LINQ und POCOs mit besserer Unterstützung für bestehende Datenbanken (es gibt Dinge, die in EF Code First ziemlich schwierig zu mappen sind), und existierende Unterstützung für asynchronen Betrieb (EF ist jetzt 5.0, 6.0 hat async) - (Update: EF6 ist das neueste und seine Async-Unterstützung ist großartig. Ihr Massen-Löschen ist jedoch schrecklich und sollte wie Pest vermieden werden, um auf SQL zu verzichten.)
Insbesondere NHibernate ist das Biest für die vorhandene db-Unterstützung, aber es ist ein bisschen eine Konfigurationsarbeit und scheinbar politische Machtkämpfe haben dazu geführt, dass die Dokumentation für verschiedene Versionen und Forks in Konflikt geraten ist.
Viel einfacher sind viele Micro ORMs "- dieser Link ist eine kurze Liste von 2011, aber wenn du herumstocherst, findest du 30 oder so in .Net. Einige erzeugen bessere oder weniger optimale Abfragen, manche gar keine, manche machen Sie SQL schreiben (benutzen Sie diese nicht) - Sie müssen herumstochern, um zu entscheiden, welches für Sie ist. Dies kann eine größere Forschungsaufgabe sein, aber ich vermute, dass die einfache Konfiguration und die kleine Lernkurve für eine dieser Möglichkeiten am besten geeignet sind.
Wenn Sie gleichzeitig eine Verbindung zu allen 50 Datenbanken von einer App herstellen, müssen Sie 50 DbContexte wie:
instanziieren %Vor%Angenommen, du hast kleine Wrapperklassen wie:
gemacht %Vor%Dabei ist CoreDbContext die Haupt-EF-Klasse in Ihrem Projekt, die DbContext (Standardteil eines EF-Projekts) erweitert.
Wenn Sie nur den einen pro App verwenden, wird ein beliebiges EF-Tutorial verwendet tue .
Der einzige große Trick besteht darin, diese Dbs zu migrieren, wenn Schemaänderungen auftreten. Zwei grundlegende Ansätze dort. In jedem Fall können Sie eine Sicherungskopie erstellen und eine Kopie von ihnen lokal wiederherstellen, um Ihre Migrationen gegen sie zu testen ( update-database -f -verbose ). Wenn Sie nicht riskieren, dass Datenfehler wie das Ändern einer Spalte in NOT NULL und das Auffinden Ihrer lokalen Testinstanz keine Nullen aufwiesen, hat ein Client dies getan, kaboom. Sobald Sie mit der Arbeit fertig sind, entscheiden Sie, wie Sie die Produktion aktualisieren möchten. Es gibt viele Möglichkeiten, wie Sie ein benutzerdefiniertes Roll-Forward- / Back-Tool schreiben (oder eines finden) können, indem Sie SQL-Skripts in git einchecken, einen DBA einstellen oder viel einfacher:
Speichern Sie die Migration in SQL ( update-database -script ) und führen Sie sie für die aktuelle Produktionsdatenbank aus.
Fügen Sie Einträge für jede db zu Web.Config hinzu und erstellen Sie eine Projektkonfiguration für jede von ihnen wie "DbDeployClient1", "DbDeployClient2", etc. In jedem von diesen machen Sie eine Builddefinition wie DbDeployClient1, und fügen Sie diese dann zu Ihrem hinzu DbContext-Klasse:
%Vor%Damit können Sie schnell zu Ihrer DbDeploy-Konfiguration wechseln und die Migration direkt von Visual Studio aus für die Zieldatenbank ausführen. Wenn Sie dies tun, müssen Sie einen Port, vorzugsweise nur in Ihrer IP, auf der tatsächlichen SQL Server-Instanz, die Sie migrieren, vorübergehend öffnen. Eine feine Sache ist, dass Sie klare Fehler von Ihrer Migration genau dort bekommen, und volle Rollback-Fähigkeit, ohne wirkliche Arbeit - all diese Rollback-Unterstützung, die Sie nutzen, ist nur ein Teil von EF. Und ein Entwickler kann das ohne einen Haufen anderer Engpässe tun. Aber es hat viele Möglichkeiten, Risiken zu reduzieren und die Automatisierung zu verbessern.
Tags und Links sql-server c#