2013-04-12 3 views
0

У меня есть объект, который имеет свойство типа Тип:EF Code First - Свойство типа Тип

public ScheduledJob 
{ 
    public int ID { get; set; } 
    public Type JobType { get; set; } 
    public string JobParameters { get; set; } 
} 

Когда я генерировать код-первых миграций, я получаю следующее сообщение об ошибке:

System.ArgumentNullException: Value cannot be null. 
Parameter name: key 
    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key) 
    at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value) 
    at System.Data.Entity.ModelConfiguration.Configuration.Mapping.SortedEntityTypeIndex.Add(EdmEntitySet entitySet, EdmEntityType entityType) 
    at System.Data.Entity.ModelConfiguration.Configuration.Mapping.EntityMappingService.Analyze() 
    at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.ConfigureEntityTypes(DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest) 
    at System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.Configure(DbDatabaseMapping databaseMapping, DbProviderManifest providerManifest) 
    at System.Data.Entity.DbModelBuilder.Build(DbProviderManifest providerManifest, DbProviderInfo providerInfo) 
    at System.Data.Entity.DbModelBuilder.Build(DbConnection providerConnection) 
    at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext) 
    at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input) 
    at System.Data.Entity.Internal.LazyInternalContext.InitializeContext() 
    at System.Data.Entity.Internal.LazyInternalContext.get_CodeFirstModel() 
    at System.Data.Entity.Infrastructure.EdmxWriter.WriteEdmx(DbContext context, XmlWriter writer) 
    at System.Data.Entity.Migrations.Extensions.DbContextExtensions.<>c__DisplayClass1.<GetModel>b__0(XmlWriter w) 
    at System.Data.Entity.Migrations.Extensions.DbContextExtensions.GetModel(Action`1 writeXml) 
    at System.Data.Entity.Migrations.Extensions.DbContextExtensions.GetModel(DbContext context) 
    at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration, DbContext usersContext) 
    at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration) 
    at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.GetMigrator() 
    at System.Data.Entity.Migrations.Design.ToolingFacade.GetPendingMigrationsRunner.RunCore() 
    at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.Run() 

Каков наилучший способ заставить этот сценарий работать?

РЕДАКТИР @ пост NSGaga в:

Вся модель (упрощенно) заключается в следующем:

Все работы объектов реализовать следующий интерфейс:

public interface IJob 
{ 
    Guid ID { get; set; } 
    void Run(); 
} 

Каждый из рабочих мест имеет свои собственные свойства, используемые в качестве своего рода параметра:

public class ProcessMedia : IJob 
{ 
    public Guid ID { get; set; } 

    public int MediaContentID { get; set; } 

    public void Run() 
    { 
     if(MediaContentID <= 0) 
      throw new Exception("Missing parameter MediaContentID"); 
     //work 
    } 
} 

Я использую эту модель для асинхронной системы обработки заданий, которая отлично работает. Теперь я пытаюсь создать планировщик, где я могу дать ему тип задания и параметры (сериализованные для строки) и запустить его с интервалами.

+1

Сохраните полное имя типа в виде строки. –

+0

Я делал это раньше, я просто проверял, есть ли ярлык. –

ответ

1

Посмотрите на этот пост, я сделал несколько дней назад ...

How should I define a field that can take various data types in EF?

Почему вы это делаете?

Вам почти не нужно сохранять Type как таковой.

@David mentioned already what to do.

Но я буду препятствовать вам идти таким путем, но скорее переосмыслить.

Код EF в первую очередь касается наличия «строго типизированных» объектов. У вас может быть приятное «наследование», работающее без необходимости сохранения типа.

Если вам нужно что-то вроде «перечисляемого типа» из ограниченного числа - используйте перечисление или int.

Вы можете разместить свою модель, и я укажу вам, если она может быть изменена.


Я думаю, вы могли бы использовать наследование за то, что вам нужно.
Создание различных типов объектов.

например. взгляните на это решение здесь (мой пост ранее)
Multiple Inheritance Levels in EF Code Firs
... и дайте мне знать, если проблемы, вопросы при попытке чего-то.

Возможно, проще использовать TPH (как будто он там), все они хранятся в одной таблице - и вы обычно получаете меньше проблем.

+0

Я обновил исходное сообщение, чтобы показать больше деталей модели и рассуждений. –

+0

Я обновил - взгляните и дайте мне знать. – NSGaga

+0

Я отмечаю это как правильный ответ учебника, но это не лучший ответ за то, что я строю. Если бы я использовал наследование, разработчикам потребовалось бы создавать сценарий переноса данных каждый раз при создании нового задания. Я бы очень хотел избежать этого, так как мы можем в итоге получить много разных типов заданий. Я пошел с предложением @ davin-tryon, чтобы сохранить квалифицированное имя сборки и получить от этого тип. –

Смежные вопросы