Отличаются ли большие модели баз данных EF от производительности приложения

Question

Наш проект зависит от одной большой базы данных MSSQL. Эта база данных доступна для многих других приложений. Некоторые из них используют первую модель базы данных EF. В этой базе данных имеется более 300 таблиц. Некоторые из них мы должны использовать некоторые из них для других частей приложения. Когда мы перерабатываем базу данных, EF создает модель со всеми таблицами без каких-либо проблем. Иногда наш код использует только одну таблицу, но нам еще нужно объявить большую модель.

Мой вопрос заключается в том, что производительность пострадает от приложения, если мы всегда инициализируем модель с большим количеством таблиц в ней.

Что происходит за кулисами, когда мы имеем таких код

public string peaceOfData(int id) 
{ 
    using (modelWhit500tables largeMode = new modelWhit500tables()) 
    { 
     return largeMode.onlyOneTable.Find(id).data; 
    } 
} 

Наших приложений в основном MVC приложение, содержащее ряд веб-API контроллеров.

Нам нравится иметь одну большую модель из-за простоты уровня базы данных и простоту обслуживания для изменения дизайна базы данных.

Answer 1

я не смог бы прокомментировать внутренностей EF, хотя this post отвечает на ваш вопрос, по крайней мере, в части:

Giant контексты

Даже если вы прекомпилировать взгляды, Entity Framework до сих пор должен работать, когда контекст сначала инициализируется, и эта работа пропорциональна количеству объектов в вашей модели. Для всего лишь несколько столов, о которых не стоит беспокоиться.

Однако общий способ работы с EF состоит в том, чтобы автоматически генерировать контекст из ранее существовавшей базы данных и просто импортировать все объекты. В то время это было разумным, так как оно максимизирует вашу способность работать с базой данных . Так как даже довольно скромные базы данных могут содержать сотни объектов, быстродействие производительности выходят из-под контроля, а время запуска может варьироваться в минутах. Это стоит ли учитывать, действительно ли ваш контекст должен знать о всей схеме, а если нет, то удалить эти объекты.

Важно отметить, что в первый раз, когда экземпляр приложения обращается к контексту БД, контекст будет проходить процесс инициализации. Это то, о чем говорится в приведенной выше цитате. Это происходит только один раз для приложения или веб-службы, даже если контекст удаляется вашим кодом. Это одноразовый показатель производительности для вашего приложения.Возможно, вы захотите вызвать это явно при запуске своего приложения, вместо того, чтобы наказать первого пользователя для доступа к вашему приложению для этого.

Рекомендации по производительности для EF описаны в this MSDN article. Самый большой удар, который вы, скорее всего, получите с загрузкой модели и метаданных отображения. В вашем случае, для MVC и Web API приложений, это зависит от того, как вы ваши домены приложений определены:

Answer 2

Вместо использования сгенерированной модели со всеми 300 таблицами вы можете создать свой собственный dbContext с использованием подхода, основанного на кодах. Затем вы можете работать с уменьшенным видом поверхности базы данных. Вы даже можете игнорировать поля, которые ваше приложение не нужно для каждой таблицы, а также этот способ для повышения производительности. В качестве упрощенного примера используется только 2 таблицы из 300.

общественный класс Заказчик { public int id {get; набор;}

public string Custno { get; set; } 
    public string Name { get; set; } 
    public decimal Balance { get; set; } 

    // The table other fields are ignored... 

    public List<CustomerAddress> Addresses { get; set; } 


    } 
} 

public class CustomerAddress 
{ 
    public int id { get; set;} 

    public int Customerid { get; set; } 

    public string Address1 { get; set; } 
    public string Address2 { get; set; } 
    public string Cityname { get; set; } 
    public string Statename { get; set; } 
    public string Countryname { get; set; } 
    public string Zipname { get; set; } 

    public Customer Customer { get; set; } 


} 
    public class CustomerMap() 
    { 

     ToTable("Customers"); 

     Property(p => p.Id).HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity); 
     HasKey(k => k.Id); 

     Property(p => p.Custno).HasMaxLength(8).IsRequired(); 
     Property(p => p.Name).HasMaxLength(120).IsRequired(); 
     Property(p => p.Balance).HasPrecision(18, 2); 

     HasMany(a => a.Addresses).WithRequired(x => x.Customer).HasForeignKey(k => k.Customerid); 

    } 

    public class CustomerAddressMap() 
    { 

     ToTable("CustomerAddresses"); 

     Property(p => p.Id).HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity); 
     HasKey(k => k.Id); 


     Property(p => p.Address1).HasMaxLength(120); 
     Property(p => p.Address2).HasMaxLength(120); 
     Property(p => p.Cityname).HasMaxLength(40); 
     Property(p => p.Countryname).HasMaxLength(40); 
     Property(p => p.Statename).HasMaxLength(40); 
     Property(p => p.Zipname).HasMaxLength(6); 


     HasRequired(x => x.Customer).WithMany(a => a.Addresses).HasForeignKey(k => k.Customerid).WillCascadeOnDelete(false); 

    } 

    public class YourAppContext : DbContext 
{ 
    public YourAppContext() 
     : base("YourAppContext") 
    { 
     Database.SetInitializer<YourAppContext>(null);  
    } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     modelBuilder.Configurations.Add(new CustomerMap());    
     modelBuilder.Configurations.Add(new CustomerAddressMap());  

    } 


    public DbSet<Customer> Customer { get; set; } 
    public DbSet<CustomerAddress> CustomerAddresses { get; set; } 


} 

Таким образом, вы можете использовать YourAppContext запрашивать и обновлять только таблицы и поля, которые нужно.