私の例では、議論のために擬似C＃コードを使用する予定ですが、これは単一の言語またはデータベースツールに固有のものではありません。データモデルによって駆動されるリソースIDは、リソースまたはデータベースの側面ですか？
私はnew Customer()を保存するときRavenDBを使用したシンプルなモデル
Customer { string Id }
を取る、それは "顧客/ 234" とし、実行時に私のためにIDを生成します。このシナリオでは、IDはRavenDBの面であると受け入れても問題ありません。基本的には、人間が理解できる意味を持たず、グローバルユニークさの目標（このデータベース）を達成するだけの識別子を作成するので、これは絶対にGuid.NewGuid().ToString()と変わりません。これは間違いなくGUIDのより良いバージョンであり、より良いURLを作成し、16のランダムな16進数の文字列よりはるかに簡単に必要な場合、人間がIDを伝えることを許可します。別のシナリオのテイクで
：このシナリオでは
User { string UserName, string Id }
私はユニークな番号とは対照的に、私のIDに本当の意味論的な意味を置きたいです。
はRavenDBでは、これを達成することができるに似て：あなたはで終わるだろうこのストア操作中に
は、私はまた、ユーザーを持つのではなく、することで、この近づくことができ、「ユーザ/ dotnetchris」
store.Conventions.DocumentKeyGenerator = (entity) =>
{
User user = entity as User;
if(user == null)
return defaultKeyGeneration (entity);
return "Users/" + user.UserName;
}
読み取り専用のプロパティを使用して、IDの単純なプロパティを持っている：
User {
string Id { get { return "Users/" + UserName }
私はこのconstruのために適切な場所であるこれらのかを決めるに苦労していますct。
これはあなたに実際にUsers.Where(user.UserName == "dotnetchris")
私がグローバルに使用しているすべての点私は自分のデータの範囲を指していますが、必ずしもGUID **が真に**ユニークな方法で世界的にユニークであるとは限りません。 –
私は実際にこれらのソリューションの1つを実装しようとしています。私は世代がDocumentKeyGeneratorにあるのが好きです。なぜなら、それは鍵生成コードを単一の場所に分離するからです。しかし、RavenDbはIdを使ってエンティティをロードできるLoadを提供しています。また、適切なプレフィックスを持つIDをまだ持っていない場合は、キー生成システムの外でプレフィックスを適用する方法が必要です。 – ShaneH
@ ShaneH私はそれが1の場所に隔離されていることに同意しますが、私はあなたのオブジェクトのすべてがその理解を失うので、それが良いことだとは思っていません。 Loadを満たすためにkeyPartからこれらのIDを構築する必要があれば、 'Id.For（this.RouteData）'のような振る舞いをするクラスを作成します。これはジェネリック型のスイッチになります。 HenriFormat（ルートデータ） 'https://gist.github.com/2170953 –