EntityFrameworkを使用する新しいプロジェクトを開始しています。私はデータベースを作成する方法のオプションを調査し、コードファーストマイグレーションが最も理にかなっていることを発見しました(理由を知る必要がある場合は下部を参照してください)。コードファーストマイグレーションでは、任意のSQLにドロップダウンできます。つまり、完全に制御できます。実際には、SQLへのドロップダウンは、いくつかの一般的なタスクでひどく繰り返されるように見えるという問題があることがわかりました。
私の目的では、移行の拡張機能がプロバイダーに依存しないことを気にしません(インライン化するSQLはそうではありません)。ただし、移行フレームワークでそのようなものを追加するための適切な継ぎ目や拡張ポイントを実際に見つけていません。
具体的な例として、MS-SQLレプリケーションのRowGuid列を指定するとします。すべての出来事は次の形をとります
Sql(
string.Format(
"Alter Table {0} Alter Column {1} Add ROWGUIDCOL",
table,
column ));
だから私は冗長性のいくつかを取り除くために静的なメソッドを書きます
Sql( MigrationHelper.SetRowGuid( table, column );
-また-
MigrationHelper.SetRowGuid(Sql, table, column); //passing the Sql method
おそらく、DbMigrationでこれらの拡張メソッドのいずれかを作成し、によってそれらにアクセスすることができますがthis.
、それでもこれは場違いに見えます:
CreateTable(
"dbo.CustomerDirectory",
c => new
{
Uid = c.Int(nullable: false),
CustomerUid = c.Int(nullable: false),
Description = c.String(nullable: false, maxLength: 50, unicode: false),
RowGuid = c.Guid(nullable: false),
})
.PrimaryKey(t => t.Uid)
.ForeignKey("dbo.Customer", t => t.CustomerUid);
this.SetRowGuid( Sql, "dbo.CustomerDirectory", "RowGuid" );
//Custom method here because of desired naming convention of Constraint
this.SetDefaultConstraint( Sql, "dbo.CustomerDirectory", "''" ):
それはひどくはありませんが、それでも私にとってはハックのように感じます。テーブル名を繰り返す必要があり、生成された列名が正しいことを確認する必要があります。テーブル名を何度も繰り返す必要があると思いますが、列も繰り返す必要があります。それでも、テーブル名と列名の両方がすべてわかっている場所で発生したテーブル宣言に追加するために、私が実際にやろうとしていること。
ただし、流暢なインターフェイスを拡張したり、一貫性のある方法でコードの最初の移行を拡張したりするための適切な拡張ポイントを見つけることができませんでした。私は何かが足りないのですか?誰かがこれを行うための良い方法を見つけましたか?
私がこの状況にある理由に関するいくつかの正当化:
いくつかの理由で、一般的なカスタム属性ソリューションを使用して非マッピングデータベースを示す一般的なソリューションのように見えるものが好きではありませんでしたが、移行によって自動的に取得されないため、余分なメンテナンスが必要になります。モデルファーストのソリューションは、データベースを完全に制御できないため、廃止されました。データベース-最初はコントロールのおかげで魅力的でした。ただし、Code-FirstMigrationsが提供するすぐに使用できる変更管理機能はありません。したがって、[コードファースト]モデル駆動型の変更は自動的に行われ、維持するものが1つしかないため、コードファースト移行が勝者のように見えました。