EntityFramework用のHiLOキージェネレーターを実装した人はいますか。
HiLoの詳細については、こちらをご覧ください。IDを選択することの欠点の詳細については、http ://fabiomaulo.blogspot.com/2009/02/nh210-generators-behavior-explained.htmlを読むことをお勧めします。
EntityFramework用のHiLOキージェネレーターを実装した人はいますか。
HiLoの詳細については、こちらをご覧ください。IDを選択することの欠点の詳細については、http ://fabiomaulo.blogspot.com/2009/02/nh210-generators-behavior-explained.htmlを読むことをお勧めします。
はい、誰かが Entity Framework 用に HiLO を実装しました。私は自分でテストしていません: http://joseoncode.com/2011/03/23/hilo-for-entityframework/
答えてくれてありがとう
待つしかないと思います :-) EF は正しい方向に進んでおり、CTP5 が大好きです。
「ラップ」からの回答についてコメントする必要があります。ランダムな Guid をインデックスとして使用すると、SQL Server のパフォーマンスが大幅に低下する可能性があります。これは、各挿入のインデックスが断片化されるためです。これは、SQL サーバーのパフォーマンスに大きな問題を抱えていた新しい会社で働き始めたときに、現実の世界から学んだことです。guid から bigint に移動すると、問題が解決しました。常に再インデックスする必要はありませんでした。
残念ながら、EF には NHibernate のような POID ジェネレーターに非常に近いものはありませんが、同様の機能が EF の次のリリースに含まれるという噂を耳にします。(なに?!? Microsoft が競合他社の優れたアイデアを採用するなんて、ありえない!)
HiLo の Lo 部分を自分たちで処理するのはそれほど難しいことではありませんが、Hi 部分は EF に協力してもらうことができないと難しいでしょう。それには、マイクロソフトが EF の一部をリファクタリングする必要があります。これがおそらく、誰もそれを実行しようとせず、github や codeplex でオープン ソース プロジェクトとして公開しようとしなかった理由です。
それまでの間、オフラインでレコードを生成し、後で同期するために使用したのは、グローバルに一意の識別子です。
var id = Guid.NewGuid();
次に、それをテーブルの ID に割り当てます。これは、SaveChanges で実行できます。
HiLoほど良くないことはわかっていますが、これまでのところ近いです. オフラインで作業でき、有効で一意の ID を保証できるという利点があります。
IMO エンティティ フレームワークには、NHibernate のジェネレータに相当するものはありません。EF で使用できる唯一の機能は、Identity に設定できる StoreGeneratedPattern です。StoreGeneratedPattern は、DB がキーを割り当て、キーが挿入操作の一部として EF コンテキストに返されることを意味します (Guid ではより困難です)。
NHibernate POID ジェネレーターに相当するものが必要な場合は、SaveChanges をオーバーライドするか、ObjectContext で SavingChanges を処理する必要があります。次に、選択した POID アルゴリズムから挿入されたすべてのエンティティに ID を手動で割り当てることができますが、アルゴリズムを実装する必要があります。
Entity Framework 7 がサポートされています: https://channel9.msdn.com/Blogs/Seth-Juarez/Key-Generation-Strategies-in-Entity-Framework-7
public class ExampleContext : BaseContext {
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ForSqlServerUseSequenceHiLo();
}
}