Ein Vorteil von Code First ist die Tatsache, dass man recht einfach das DBMS wechseln kann. Das geht zwar ohne Code First auch, aber in diesem Fall muss das Storage Model im Entity Data Model angepasst werden. Bei Code-First-Projekten ist hingegen lediglich der Treiber auszutauschen.
Die nachfolgende Beschreibung zeigt, wie man ein Code First-Projekt auf ORACLE umstellen kann. Dazu kommen die Treiber von devart [1] zum Einsatz.
1. devart dotConnect for Oracle von [1] herunterladen und installieren. Anmerkung: Die freie dotConnect Express-Variante unterstützt Entity Framework nicht. Zum Testen kann man die Trail-Version der Professional-Edition verwenden.
2. Die folgenden Assemblies einbinden: DevArt.Data, DevArt.Data.Oracle, DevArt.Data.Oracle.Entity
3. Falls keine benutzerdefinierte ConnectionFactory verwendet wird, ist nun der Connection-String in der web.config bzw. app.config anzupassen. Ansonsten muss die benutzerdefinierte ConnectionFactory analog dazu modifiziert werden.
<configuration>
<connectionStrings>
<!--
<add name="HotelDbContext" providerName="System.Data.SqlClient" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=HotelDb;Integrated Security=True;Pooling=False;Encrypt=True" />
-->
<add
name="HotelDbContext"
connectionString="Data Source=localhost;User Id=...;Password=...;"
providerName="Devart.Data.Oracle"/>
</connectionStrings>
</configuration>
|
4. In einer perfekten Welt wäre das nun alles. In dieser Welt sind noch zwei Anpassungen vorzunehmen. Zum einen ist in der Context-Implementierung anzugeben, dass die ColumnTypeCasingConvention nicht anzuwenden ist, da Oracle damit nicht klar kommt.
public class HotelDbContext : DbContext
{
public DbSet<Hotel> Hotels { get; set; }
public DbSet<HotelBuchung> HotelBuchungs { get; set; }
public DbSet<KontoAbbuchung> KontoAbbuchungs { get; set; }
public DbSet<KreditkartenZahlung> KreditkartenZahlungs { get; set; }
public DbSet<Region> Regions { get; set; }
public DbSet<Zahlung> Zahlungs { get; set; }
public DbSet<ZahlungBase> ZahlungBases { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
// Für ORA:
modelBuilder.Conventions.Remove<ColumnTypeCasingConvention>();
[…]
}
}
|
5. Falls keine Schemata spezifiziert wurden, muss auf Treiber-Ebene die Verwendung dieser abschalten werden, da standardmäßig das Schema ‚dbo‘, welches unter SQL Server immer existiert, herangezogen wird.
static void Main(string[] args)
{
Database.SetInitializer(new DropCreateDatabaseAlways<HotelDbContext>());
var config = OracleEntityProviderConfig.Instance;
config.Workarounds.IgnoreSchemaName = true;
[…]
}
|
Zusätzlich hat es sich bewährt, die Länge von Strings mit der FluentAPI oder den DataAnnotations zu beschränken. Macht man das nicht, werden CLOB-Spalten eingerichtet, was in den meisten Fällen nicht erwünscht sein dürfte. Das war’s dann auch schon. Wird die Anwendung nun ausgeführt, sollte Sie unter ORACLE laufen.
[1] http://www.devart.com/