رمز EF أولا 4.1: "ميراث متعددة" (هو أ) السؤال

Question

أحاول طراز نوع من علاقات "ميراث متعددة" مع رمز EF 4.1 أولا. هنا مثال على ما أحاول القيام به.

دعنا نقول أنني أحاول طراز الطريقة التي يتفاعل المستخدم مع طلبي باستخدام كائن "مستخدم". يستخدم هذا، كونه الطبقة الأساسية، لوصف المستخدم الحالي عندما لا يقومون بأي شيء على وجه الخصوص (مثل زيارة الصفحة الرئيسية). قد تبدو مثل هذا: giveacodicetagpre.

الآن، إذا كنت ترغب في إنشاء تمثيل لنفس المستخدم، لكن في جزء مختلف من الموقع، كما يقول، كمتغير، قد يبدو مثل هذا: giveacodicetagpre.

وهلم جرا، وهكذا دواليك. عندما أذهب لإدراج المتسوق الذي يحتوي على إدخال مستخدم موجود مسبقا، فإنه يلقي استثناءا لأن PK مأخوذة بالفعل في جدول المستخدم.

هل هناك أي طريقة لنموذج العلاقة (ISA) مع رمز EF أولا؟ أو سأكون عالقا مع شيء مثل هذا؟ giveacodicetagpre.

أود الالتزام برمز أولا ونموذج العلاقات مباشرة في DBContext، لكنني لا أستطيع معرفة كيفية فعل شيء مثل هذا. شكرا!

تحرير:

لذلك، أحاول أن أفعل شيئا مثل هذا: giveacodicetagpre.

مثل استخدام الأدوار الموجهة للكائنات، أعتقد. أريد استخدام نفس PK لكل عملية التمثيل من هذا المستخدم، لكن تخزين جميع معلوماتهم الأساسية في فئة أساسية تسمى المستخدم. أعلم أن هذا ممكن إذا كتبت SQL الخاصة بي، بالطبع، لكنني أريد أن أرى ما إذا كان بإمكان رمز EF أولا القيام بذلك، أيضا.

Answer 1

Yes, you can do it the way you describe in your first two code examples.

I think you just need to define a mapping, which you'll want to do in your OnModelCreating function of your DataContext in addition to having your classes set up right. How you do it depends on what mapping scheme you're using. I went for Table-Per-Type (TPT) in my most recent project, so I had something like this:

modelBuilder.Entity<User>().ToTable("Users");
modelBuilder.Entity<Shopper>().ToTable("Shoppers");
modelBuilder.Entity<OtherUser>().ToTable("OtherUsers");

Let me know if that doesn't work for you and I'll see what I can do.

Edit:

Having seen your clarification below, I can't think of a way to do that. You'd have to keep each objects stored separately (having EF treat a Shopper as just a Shopper, not a Shopper and a User), even though they share common data. That could lead to data mismatches (if, say, Shopper got its LastName updated but User didn't). I think you might be better off going with something like:

public class User
{
    public virtual Guid ID { get; set; }
    public virtual string FirstName { get; set; }
    public virtual string LastName { get; set; }
    public virtual ShopperInfo { get; set; }
}

public class ShopperInfo
{
    public virtual ICollection<Order> Orders { get; set; }
}

and then when you need to treat User as a Shopper, you just access the ShopperInfo (and if its not there, you create it). EF will be able to properly set that up for you no problem.

Though if you're going to have a lot of types of users, that might get cumbersome. Just a suggestion though - I think its a bit cleaner.