Dbset c что это

• Выполнение с задержкой (lazy loading)
• Может быть перезагружен:

AsQueryable(IEnumerable) или AsQueryable(IEnumerable) 

Пример использования AsQueryable в простейшеем случае:

public IEnumerable GetEmails(out int totalRecords, Guid? deviceWorkGroupID, DateTime? timeStart, DateTime? timeEnd, string search, int? confirmStateID, int? stateTypeID, int? limitOffset, int? limitRowCount, string orderBy, bool desc) < var r = new List(); using (var db = new GJobEntities()) < var query = db.Emails.AsQueryable(); if (timeStart != null && timeEnd != null) < query = query.Where(p =>p.Created >= timeStart && p.Created if (stateTypeID != null && stateTypeID > -1) < query = query.Where(p =>p.EmailStates.OrderByDescending(x => x.AtTime).FirstOrDefault().EmailStateTypeID == stateTypeID); > if (confirmStateID != null && confirmStateID > -1) < var boolValue = confirmStateID == 1 ? true : false; query = query.Where(p =>p.IsConfirmed == boolValue); > if (!string.IsNullOrEmpty(search)) < search = search.ToLower(); query = query.Where(p =>(p.Subject + " " + p.CopiesEmails + " " + p.ToEmails + " " + p.FromEmail + " " + p.Body) .ToLower().Contains(search)); > if (deviceWorkGroupID != Guid.Empty) < query = query.Where(x =>x.SCEmails.FirstOrDefault().SupportCall.Device.DeviceWorkGroupDevices.FirstOrDefault(p => p.DeviceWorkGroupID == deviceWorkGroupID) != null); > totalRecords = query.Count(); query = query.OrderByDescending(p => p.Created); if (limitOffset.HasValue) < query = query.Skip(limitOffset.Value).Take(limitRowCount.Value); >var items = query.ToList(); // Получаем все отфильтрованные записи foreach (var item in items) < var n = new EmailView < SentTime = item.SentTime, IsConfirmed = item.IsConfirmed, Number = item.Number, Subject = item.Subject, IsDeleted = item.IsDeleted, ToEmails = item.ToEmails, Created = item.Created, CopiesEmails = item.CopiesEmails, FromEmail = item.FromEmail, >; // Другой код для заполнения класса-представления r.Add(n); > > return r; > 

Волшебство простого чтения

Если вам не нужно менять данные, только отобразить используйте .AsNoTracking() метод.

Медленная выборка

var blogs = context.Blogs.ToList();

Быстрая выборка (только на чтение)

var blogs = context.Blogs.AsNoTracking().ToList();

Чувствую, вы немного уже размялись?

Типы загрузки связанных данных

Для тех, кто забыл, что такое lazy loading.

Ленивая загрузка (Lazy loading) означает, что связанные данные прозрачно загружаются из базы данных при обращении к свойству навигации. Подробнее читаем тут .

И заодно, напомню о других типах загрузки связанных данных.

Активная загрузка (Eager loading) означает, что связанные данные загружаются из базы данных как часть первоначального запроса.

using (var context = new BloggingContext()) < var blogs = context.Blogs .Include(blog =>blog.Posts) .ThenInclude(post => post.Author) .ThenInclude(author => author.Photo) .Include(blog => blog.Owner) .ThenInclude(owner => owner.Photo) .ToList(); > 

Внимание! Начиная с версии EF Core 3.0.0, каждое Include будет вызывать добавление дополнительного JOIN к запросам SQL, создаваемым реляционными поставщиками, тогда как предыдущие версии генерировали дополнительные запросы SQL. Это может значительно изменить производительность ваших запросов, в лучшую или в худшую сторону. В частности, запросы LINQ с чрезвычайно большим числом операторов включения могут быть разбиты на несколько отдельных запросов LINQ.

Явная загрузка (Explicit loading) означает, что связанные данные явно загружаются из базы данных позднее.

using (var context = new BloggingContext()) < var blog = context.Blogs .Single(b =>b.BlogId == 1); var goodPosts = context.Entry(blog) .Collection(b => b.Posts) .Query() .Where(p => p.Rating > 3) .ToList(); >

Рывок и прорыв! Двигаемся дальше?

Готовы ускориться еще больше?

Чтобы резко ускориться при выборке сложно структурированных и даже ненормализованных данных из реляционной базы данных есть два способа сделать это: используйте индексированные представления (1) или что еще лучше – предварительно подготовленные(вычисленные) данные в простой плоской форме для отображения (2).

(1) Индексированное представление в контексте MS SQL Server

Индексированное представление имеет уникальный кластеризованный индекс. Уникальный кластерный индекс хранится в SQL Server и обновляется, как и любой другой кластерный индекс. Индексированное представление является более значительным по сравнению со стандартными представлениями, которые включают сложную обработку большого количества строк, например, агрегирование большого количества данных или объединение множества строк.

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

Представление индекса имеет определенную стоимость в виде производительности. Если мы создаем индексированное представление, каждый раз, когда мы изменяем данные в базовых таблицах, SQL Server должен поддерживать не только записи индекса в этих таблицах, но также и записи индекса в представлении. В редакциях SQL Server для разработчиков и предприятий оптимизатор может использовать индексы представлений для оптимизации запросов, которые не указывают индексированное представление. Однако в других выпусках SQL Server запрос должен включать индексированное представление и указывать подсказку NOEXPAND, чтобы получить преимущество от индекса в представлении.

(2) Если нужно сделать запрос, требующий отображения более трех уровней связанных таблиц в количестве три и более c повышенной CRUD нагрузкой, лучшим способом будет задуматься о том, чтобы периодически вычислять результирующий набор, сохранять его в таблице и использовать для отображения. Результирующая таблица, в которой будут сохраняться данные должна иметь Primary Key и индексы по полям поиска в LINQ.

Что насчет асинхронности?

Да! Используем ее где только можно! Вот пример:

public void Do() < var myTask = GetFederalDistrictsAsync (); foreach (var item in myTask.Result) < //Ваш код >> public async Task> GetFederalDistrictsAsync()

И да, ничего не забыли для повышения производительности? Бууум!

return await context.FederalDistricts.AsNoTracking().ToListAsync();

Внимание: метод Do() добавлен для демонстрационных целей только, с целью указать работоспособность метода GetFederalDistrictsAsync(). Как правильно заметили мои коллеги тутнужен другой пример чистой асинхронности.

И давайте я его приведу на основе понятия компонента представления в ASP .NET Core:

// Класс компонента public class PopularPosts : ViewComponent < private readonly IStatsRepository _statsRepository; public PopularPosts(IStatsRepository statsRepository) < _statsRepository = statsRepository; >public async Task InvokeAsync() < // Вызов нашего метода без изменений из выделенного репозитория бизнес-логики var federalDistricts = await _statsRepository.GetFederalDistrictsAsync(); var model = new TablePageModel() < FederalDistricts = federalDistricts, >; return View(model); > > // Далее /// 
/// Интерфейс бизнес-логики для получения хммм. чего-либо ///
 public interface IStatsRepository < /// 
/// Получение списка федеральных округов и их субъектов федерации ///
 /// IEnumerable FederalDistricts(); /// 
/// Получение списка федеральных округов и их субъектов федерации /// Асинхронно. ///
 /// Task GetFederalDistrictsAsync(); > /// 
/// Бизнес-логика для получения хммм. чего-либо ///
 public class StatsRepository : IStatsRepository < private readonly DbContextOptionsBuilderoptionsBuilder = new DbContextOptionsBuilder(); private readonly IConfigurationRoot configurationRoot; public StatsRepository() < IConfigurationBuilder configurationBuilder = new ConfigurationBuilder() .SetBasePath(Environment.CurrentDirectory) .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true); configurationRoot = configurationBuilder.Build(); >public async Task GetFederalDistrictsAsync() < var conn = configurationRoot.GetConnectionString("EFCoreTestContext"); optionsBuilder.UseSqlServer(conn); using var context = new EFCoreTestContext(optionsBuilder.Options); return await context.FederalDistricts.Include(x =>x.FederalSubjects).ToListAsync(); > public IEnumerable FederalDistricts() < var conn = configurationRoot.GetConnectionString("EFCoreTestContext"); optionsBuilder.UseSqlServer(conn); using var ctx = new EFCoreTestContext(optionsBuilder.Options); return ctx.FederalDistricts.Include(x =>x.FederalSubjects).ToList(); > > // Вызов компонента происходит в данном примере на странице Home\Index 
@await Component.InvokeAsync("PopularPosts")
 // А собственно HTML с моделю по пути Shared\Components\PopularPosts\Default.cshtml 

Напомню, когда выполняются запросы в Entity Framework Core.

При вызове операторов LINQ вы просто создаете представление запроса в памяти. Запрос отправляется в базу данных только после обработки результатов.

Ниже приведены наиболее распространенные операции, которые приводят к отправке запроса в базу данных.

• Итерация результатов в цикле for.
• Использование оператора, например ToList, ToArray, Single, Count.
• Привязка данных результатов запроса к пользовательскому интерфейсу.

Как же организовать код EF Core с точки зрения архитектуры приложения?

(1) C точки зрения архитектуры приложения, нужно обеспечить чтобы код доступа к вашей базе данных был изолирован / отделен в четко определенном месте (в изоляции). Это позволяет найти код базы данных, который влияет на производительность.

(2) Не смешивать код доступа к вашей базе данных с другими частями приложения, такими как пользовательский интерфейс или API. Таким образом, код доступа к базе данных можно изменить, не беспокоясь о других проблемах, не связанных с базой данных.

Как правильно и быстро сохранять данные с помощью SaveChanges?

Если вставляемые записи одинаковые имеет смысл использовать одну операцию сохранения на все записи.

Неправильно

using(var db = new NorthwindEntities()) < var transaction = db.Database.BeginTransaction(); try < // Вставка записи 1 var obj1 = new Customer(); obj1.CustomerID = "ABCDE"; obj1.CompanyName = "Company 1"; obj1.Country = "USA"; db.Customers.Add(obj1); //Сохраняем первую запись db.SaveChanges(); // Вставка записи 2 var obj2 = new Customer(); obj2.CustomerID = "PQRST"; obj2.CompanyName = "Company 2"; obj2.Country = "USA"; db.Customers.Add(obj2); // Сохраняем вторую запись db.SaveChanges(); transaction.Commit(); >catch < transaction.Rollback(); >> 

using(var db = new NorthwindEntities()) < var transaction = db.Database.BeginTransaction(); try < //Вставка записи 1 var obj1 = new Customer(); obj1.CustomerID = "ABCDE"; obj1.CompanyName = "Company 1"; obj1.Country = "USA"; db.Customers.Add(obj1); // Вставка записи 2 var obj2 = new Customer(); obj2.CustomerID = "PQRST"; obj2.CompanyName = "Company 2"; obj2.Country = "USA"; db.Customers.Add(obj2); // Сохранение двух или N записей db.SaveChanges(); transaction.Commit(); >catch < transaction.Rollback(); >> 

Всегда есть исключения из правила. Если контекст транзакции сложный, то есть состоит из нескольких независимых операций, то можно выполнять сохранение после выполнения каждой операции. А еще правильней использовать асинхронное сохранение в транзакции.

// Увеличение депозита его владельца public async Task AddDepositToHousehold(int householdId, DepositRequestModel model) < using (var transaction = await Context.Database.BeginTransactionAsync(IsolationLevel.Snapshot)) < try < // Добавить депозит в БД var deposit = this.Mapper.Map(model); await this.Context.Deposits.AddAsync(deposit); await this.Context.SaveChangesAsync(); // Оплатить задолжности с депозита var debtsToPay = await this.Context.Debts.Where(d => d.HouseholdId == householdId && !d.IsPaid).OrderBy(d => d.DateMade).ToListAsync(); debtsToPay.ForEach(d => d.IsPaid = true); await this.Context.SaveChangesAsync(); // Увеличение баланса владельца var household = this.Context.Households.FirstOrDefaultAsync(h => h.Id == householdId); household.Balance += model.DepositAmount; await this.Context.SaveChangesAsync(); transaction.Commit(); return this.Ok(); > catch < transaction.Rollback(); return this.BadRequest(); >> > 

Триггеры, вычисляемые поля, пользовательские функции и EF Core

Для снижения нагрузки на приложения содержащим EF Core имеет смысл применять простые вычисляемые поля и триггеры баз данных, но лучше этим не увлекаться, так как приложение может оказаться очень запутанным. А вот пользовательские функции могут быть очень полезны особенно при операциях выборки!

Параллелизм в EF Core

Если ты хочешь все запараллелить чтобы ускориться, то обломись: EF Core не поддерживает выполнение нескольких параллельных операций в одном экземпляре контекста. Следует подождать завершения одной операции, прежде чем запускать следующую. Для этого обычно нужно указать ключевое слово await в каждой асинхронной операции.

EF Core использует асинхронные запросы, которые позволяют избежать блокирования потока при выполнении запроса в базе данных. Асинхронные запросы важны для обеспечения быстрого отклика пользовательского интерфейса в толстых клиентах. Они могут также увеличить пропускную способность в веб-приложении, где можно высвободить поток для обработки других запросов. Вот пример:

public async Task> GetBlogsAsync() < using (var context = new BloggingContext()) < return await context.Blogs.ToListAsync(); >>

А что вы знаете про компилированные запросы LINQ?

Если у вас есть приложение, которое многократно выполняет структурно похожие запросы в Entity Framework, вы часто можете повысить производительность, компилируя запрос один раз и выполняя его несколько раз с различными параметрами. Например, приложению может потребоваться получить всех клиентов в определенном городе; город указывается во время выполнения пользователем в форме. LINQ to Entities поддерживает использование для этой цели скомпилированных запросов.

Начиная с .NET Framework 4.5, запросы LINQ кэшируются автоматически. Тем не менее, вы все равно можете использовать скомпилированные запросы LINQ, чтобы снизить эту стоимость в последующих выполнениях, и скомпилированные запросы могут быть более эффективными, чем запросы LINQ, которые автоматически кэшируются. Обратите внимание, что запросы LINQ to Entities, которые применяют оператор Enumerable.Contains к коллекциям в памяти, не кэшируются автоматически. Также не допускается параметризация коллекций в памяти в скомпилированных запросах LINQ.

Много примеров можно посмотреть тут.

Не делайте больших контекстов DbContext!

В общем так, я знаю многие из вас, если не почти все — lazy f_u__c_k__e_r__s и всю базу данных вы размещаете в один контекст, особенно это свойственно для подхода Database-First. И зря вы это делаете! Ниже приведен пример как можно разделить контекст. Конечно, таблицы соединения между контекстами придется дублировать, это минус. Так или иначе если у вас в контексте более 50 таблиц лучше подумать о его разделении.

Использование группировки контекста (pooling DdContext)

Смысл пула DbContext состоит в том, чтобы разрешить повторное использование экземпляров DbContext из пула, что в некоторых случаях может привести к повышению производительности по сравнению с созданием нового экземпляра каждый раз. Это также является основной причиной создания пула соединений в ADO.NET, хотя прирост производительности для соединений будет более значительным, поскольку соединения, как правило, являются более тяжелым ресурсом.

using System; using System.Diagnostics; using System.Linq; using System.Threading; using System.Threading.Tasks; using Microsoft.EntityFrameworkCore; using Microsoft.Extensions.DependencyInjection; namespace Demos < public class Blog < public int BlogId < get; set; >public string Name < get; set; >public string Url < get; set; >> public class BloggingContext : DbContext < public static long InstanceCount; public BloggingContext(DbContextOptions options) : base(options) =>Interlocked.Increment(ref InstanceCount); public DbSet Blogs < get; set; >> public class BlogController < private readonly BloggingContext _context; public BlogController(BloggingContext context) =>_context = context; public async Task ActionAsync() => await _context.Blogs.FirstAsync(); > public class Startup < private const string ConnectionString = @"Server=(localdb)\mssqllocaldb;Database=Demo.ContextPooling;Integrated Security=True;ConnectRetryCount=0"; public void ConfigureServices(IServiceCollection services) < services.AddDbContext(c => c.UseSqlServer(ConnectionString)); > > public class Program < private const int Threads = 32; private const int Seconds = 10; private static long _requestsProcessed; private static async Task Main() < var serviceCollection = new ServiceCollection(); new Startup().ConfigureServices(serviceCollection); var serviceProvider = serviceCollection.BuildServiceProvider(); SetupDatabase(serviceProvider); var stopwatch = new Stopwatch(); MonitorResults(TimeSpan.FromSeconds(Seconds), stopwatch); await Task.WhenAll( Enumerable .Range(0, Threads) .Select(_ =>SimulateRequestsAsync(serviceProvider, stopwatch))); > private static void SetupDatabase(IServiceProvider serviceProvider) < using (var serviceScope = serviceProvider.CreateScope()) < var context = serviceScope.ServiceProvider.GetService(); if (context.Database.EnsureCreated()) < context.Blogs.Add(new Blog < Name = "The Dog Blog", Url = "http://sample.com/dogs" >); context.Blogs.Add(new Blog < Name = "The Cat Blog", Url = "http://sample.com/cats" >); context.SaveChanges(); > > > private static async Task SimulateRequestsAsync(IServiceProvider serviceProvider, Stopwatch stopwatch) < while (stopwatch.IsRunning) < using (var serviceScope = serviceProvider.CreateScope()) < await new BlogController(serviceScope.ServiceProvider.GetService()).ActionAsync(); > Interlocked.Increment(ref _requestsProcessed); > > private static async void MonitorResults(TimeSpan duration, Stopwatch stopwatch) < var lastInstanceCount = 0L; var lastRequestCount = 0L; var lastElapsed = TimeSpan.Zero; stopwatch.Start(); while (stopwatch.Elapsed < duration) < await Task.Delay(TimeSpan.FromSeconds(1)); var instanceCount = BloggingContext.InstanceCount; var requestCount = _requestsProcessed; var elapsed = stopwatch.Elapsed; var currentElapsed = elapsed - lastElapsed; var currentRequests = requestCount - lastRequestCount; Console.WriteLine( $"[] " + $"Context creations/second: | " + $"Requests/second: "); lastInstanceCount = instanceCount; lastRequestCount = requestCount; lastElapsed = elapsed; > Console.WriteLine(); Console.WriteLine($"Total context creations: "); Console.WriteLine( $"Requests per second: "); stopwatch.Stop(); >

Как избежать лишних ошибок при CRUD в EF Core?

Никогда не делайте вычисления в вставку в одном коде. Всегда разделяйте формирование/подготовку объекта и его вставку/обновление. Просто разнесите по функциям: проверку введенных данным пользователем, вычисления необходимые предварительных данных, картирование или создание объекта, и собственно CRUD операцию.

Что делать, когда совсем дела плохо с производительностью приложения?

Пиво тут точно не поможет. А вот что поможет, так это разделение чтение и записи в архитектуре приложения с последующего разнесением по сокетам этих операций. Задумайтесь об использовании Command and Query Responsibility Segregation (CQRS) pattern, а также попробуйте, разделить таблицы на вставку и чтение между двумя базами данных.

Скоростных приложений вам, друзья и коллеги!

• entity framework core
• оптимизация
• c#.net

Dbset c что это

По умолчанию все типы сущностей, для которых определены в контексте данных наборы DbSet , включаются в модель и в дальнейшем сопоставляются с таблицами в базе данных. Например:

using Microsoft.EntityFrameworkCore; public class ApplicationContext : DbContext < public DbSetUsers < get; set; >= null!; public ApplicationContext() < Database.EnsureDeleted(); Database.EnsureCreated(); >protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) < optionsBuilder.UseSqlite("Data Source=helloapp.db"); >> public class User < public int Id < get; set; >public string? Name < get; set; >public int Age < get; set; >>

В данном случае, поскольку для класса User в классе контекста определено свойство типа DbSet

public DbSet Users < get; set; >= null!;

Таким образом, для сущности User будет создана таблица в бд.

Ссылочные nullable-типы и DbSet

Класс DbSet , как и другие типы, является ссылочным. А, начиная с C# 10 и .NET 6 автоматически применяется функциональность ссылочных nullable-типов. И переменные/свойства тех типов, которые не являются nullable, следует инициализировать некотором значением перед их использованием. Например, если мы напишем:

public DbSet Users

То мы столкнемся с предупреждением:

То есть нам надо инициализировать свойство типа DbSet. Хотя в этом нет большого смысла, так как контструктор базового класса DbContext гарантирует, что все свойства типа DbSet будут инициализированы и соответственно в принципе не будут иметь значение null .

Тем не менее проблема остается, поскольку мы сталкиваемся с предупреждением. Чтобы выйти из этой ситуации мы можем инициализировать свойство с помощью выражения null! , которое говорит, что данное свойство в принципе не будет иметь значение null:

public DbSet Users < get; set; >= null!;

Другое решение — инициализировать свойство значением типа Set :

public DbSet Users => Set();

Включение сущностей в модель без DbSet

Но кроме того, в модель также включаются типы, на которые есть ссылки в сущностях, которые уже включены в модель, например, через свойства DbSet.

Например, пусть у нас определены следующие сущности:

public class User < public int Id < get; set; >public string? Name < get; set; >public int Age < get; set; >// навигационное свойство public Company? Company < get; set; >> public class Company < public int Id < get; set; >public string? Name < get; set; >> public class Country < public int Id < get; set; >public string? Name < get; set; >>

И пусть у нас будет класс контекста данных:

using Microsoft.EntityFrameworkCore; public class ApplicationContext : DbContext < public DbSetUsers < get; set; >= null!; public ApplicationContext() < Database.EnsureDeleted(); Database.EnsureCreated(); >protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) < optionsBuilder.UseSqlite("Data Source=helloapp.db"); >>

После создания базы данных в ней будут созданы две таблицы: Users и Company. А третий класс — Country никак не используется в сущностях User и Company, для Country нет свойства DbSet в классе контекста, поэтому она не будет включена в контекст и для нее не будет создаваться таблица в бд.

Поскольку для типа User определен набор DbSet, то для имени таблицы будет применяться имя этого набора, а для второй таблицы будет использоваться имя класса Company.

Еще один способ включения сущности в модель представляет вызов Entity() объекта ModelBuilder в методе OnModelCreating() :

using Microsoft.EntityFrameworkCore; public class ApplicationContext : DbContext < public DbSetUsers < get; set; >= null!; public ApplicationContext() < Database.EnsureDeleted(); Database.EnsureCreated(); >protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) < optionsBuilder.UseSqlite("Data Source=helloapp.db"); >protected override void OnModelCreating(ModelBuilder modelBuilder) < modelBuilder.Entity(); > >

И если мы сейчас создадим и выполним миграции, то в базе данных будут уже три таблицы для сущностей:

Исключение из модели

Иногда возникают ситуации, когда надо, наоборот, исключить сущность из модели. Например, в примере выше сущность Company ссылается на класс Company, и, допустим, мы не хотим, чтобы в базе данных была таблица Company. В этом случае мы можем использовать Fluent API или аннотации данных.

Применение Fluent API заключается в вызове метода Ignore() :

using Microsoft.EntityFrameworkCore; public class ApplicationContext : DbContext < public DbSetUsers < get; set; >= null!; public ApplicationContext() < Database.EnsureDeleted(); Database.EnsureCreated(); >protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) < optionsBuilder.UseSqlite("Data Source=helloapp.db"); >protected override void OnModelCreating(ModelBuilder modelBuilder) < modelBuilder.Ignore(); > >

Аннотации данных предполагают установку над классом атрибута [NotMapped] :

using System.ComponentModel.DataAnnotations.Schema; public class User < public int Id < get; set; >public string? Name < get; set; >public int Age < get; set; >// навигационное свойство public Company? Company < get; set; >> [NotMapped] public class Company < public int Id < get; set; >public string Name < get; set; >>

При исключении сущности Company в базе данных будет только одна таблица Users, причем она не будет содержать столбца, который бы сопоставлялся со свойством Company класса User:

Dbset c что это

Данное руководство устарело. Актуальное руководство: Руководство по Entity Framework Core

Последнее обновление: 24.10.2018

Чтобы непосредственно начать работать с Entity Framework, создадим первое приложение. Для этого нам нужна будет, во-первых, среда разработки. В качестве среды разработки выберем Visual Studio 2017.

В окне создания проекта в левой части выберем секцию Visual C#->Windows Desktop и в центральной части окна в качестве типа проекта выберем Console App (.NET Framework) .

Теперь первым делом добавим новый класс, который будет описывать данные. Пусть наше приложение будет посвящено работе с пользователями. Поэтому добавим в проект новый класс User:

public class User < public int Id < get; set; >public string Name < get; set; >public int Age < get; set; >>

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

Надо отметить, что Entity Framework при работе с Code First требует определения ключа элемента для создания первичного ключа в таблице в бд. По умолчанию при генерации бд EF в качестве первичных ключей будет рассматривать свойства с именами Id или [Имя_класса]Id (то есть UserId). Если же мы хотим назвать ключевое свойство иначе, то нам нужно будет внести дополнительную логику на c#.

Теперь для взаимодействия с бд нам нужен контекст данных. Это своего рода посредник между бд и классами, описывающими данные. Но, у нас по умолчанию еще не добавлена библиотека для EF. Чтобы ее добавить, нажмем на проект правой кнопкой мыши и выберем в контекстном меню Manage NuGet Packages.

Затем в появившемся окне управления NuGet-пакетами в окне поиска введем слово «Entity» и выберем пакет собственно Entity Framework и установим его:

После установки пакета добавим в проект новый класс UserContext:

using System; using System.Collections.Generic; using System.Data.Entity; namespace FirstEF6App < class UserContext : DbContext < public UserContext() :base("DbConnection") < >public DbSet Users < get; set; >> >

Основу функциональности Entity Framework составляют классы, находящиеся в пространстве имен System.Data.Entity. Среди всего набора классов этого пространства имен следует выделить следующие:

• DbContext : определяет контекст данных, используемый для взаимодействия с базой данных.
• DbModelBuilder : сопоставляет классы на языке C# с сущностями в базе данных.
• DbSet/DbSet : представляет набор сущностей, хранящихся в базе данных

В любом приложении, работающим с БД через Entity Framework, нам нужен будет контекст (класс производный от DbContext) и набор данных DbSet, через который мы сможем взаимодействовать с таблицами из БД. В данном случае таким контекстом является класс UserContext.

В конструкторе этого класса вызывается конструктор базового класса, в который передается строка «DbConnection» — это имя будущей строки подключения к базе данных. В принципе мы можем не использовать конструктор, тогда в этом случае строка подключения носила бы имя самого класса контекста данных.

И также в классе определено одно свойство Users, которое будет хранить набор объектов User. В классе контекста данных набор объектов представляет класс DbSet . Через это свойство будет осуществляться связь с таблицей объектов User в бд.

И теперь нам надо установить подключение к базе данных. Для установки подключения обычно используется файл конфигурации приложения. В проектах для десктопных приложений файл конфигурации называется App.config (как в нашем случае), в проектах веб-приложений — web.config . В нашем случае, поскольку у нас консольное приложение, это файл App.config . После добавления Entity Framework он выглядит примерно следующим образом:

Содержимое файла в каждом конкретном случае может отличаться. Но в любом случае после добавления EntityFramework в проект в нем будет содержаться элемент configSections. И после закрывающего тега добавим следующий элемент:

Все подключения к источникам данных устанавливаются в секции connectionStrings , а каждое отдельное подключение представляет элемент add . В конструкторе класса контекста UserContext мы передаем в качестве названия подключения строку «DbConnection», поэтому данное название указывается в атрибуте name=»DBConnection» .

Настройку строки подключения задает атрибут connectionString . В данном случае мы устанавливаем название базы данных, с которой будем взаимодействовать — userstore.

Теперь перейдем к файлу Program.cs и изменим его содержание следующим образом:

using System; namespace FirstEF6App < class Program < static void Main(string[] args) < using(UserContext db = new UserContext()) < // создаем два объекта User User user1 = new User < Name = "Tom", Age = 33 >; User user2 = new User < Name = "Sam", Age = 26 >; // добавляем их в бд db.Users.Add(user1); db.Users.Add(user2); db.SaveChanges(); Console.WriteLine("Объекты успешно сохранены"); // получаем объекты из бд и выводим на консоль var users = db.Users; Console.WriteLine("Список объектов:"); foreach(User u in users) < Console.WriteLine(". - ", u.Id, u.Name, u.Age); > > Console.Read(); > > >

Так как класс UserContext через родительский класс DbContext реализует интерфейс IDisposable , то для работы с UserContext с автоматическим закрытием данного объекта мы можем использовать конструкцию using .

В конструкции using создаются два объекта User и добавляются в базу данных. Для их сохранения нам достаточно использовать метод Add : db.Users.Add(user1)

Чтобы получить список данных из бд, достаточно воспользоваться свойством Users контекста данных: db.Users

В результате после запуска программа выведет на консоль:

Объекты успешно сохранены Список объектов: 1.Tom - 33 2.Sam - 26

Таким образом, Entity Framework обеспечивает простое и удобное управление объектами из базы данных. При том в данном случае нам не надо даже создавать базу данных и определять в ней таблицы. Entity Framework все сделает за нас на основе определения класса контекста данных и классов моделей. И если база данных уже имеется, то EF не будет повторно создавать ее.

Наша задача — только определить модель, которая будет храниться в базе данных, и класс контекста. Поэтому данный подход называется Code First — сначала пишется код, а потом по нему создается база данных и ее таблицы.

Возникает вопрос, а где же находится БД? Чтобы физически увидеть базу данных, мы можем подключиться к ней из Visual Studio через окно View->SQL Server Object Explorer . После этого мы можем увидеть в SQL Server Object Explorer созданную базу данных, посмотреть ее строение, таблицы, открыть и даже изменить данные в таблицах:

Физически база данных по умолчанию будет располагаться в папке пользователя, в частности, у меня она размещена в каталоге C:\Users\Eugene\ , только к ее названию буде добавляться стандартное расширение mdf — userstore.mdf.