Актуальность Entity Framework 6

@MyCyberMan · Регистрация: 09.02.2020

Студворк — интернет-сервис помощи студентам

Подскажите, пожалуйста, востребован ли сейчас Entity Farmework 6 или есть более удобные средства для работы с БД?

@Usaga · 02.09.2020, 11:02

freeba, а в .NET Framework асинхронность не поддерживается? И причём тут асинхронность вообще? При использовании асинхронности, обращения к контексту идут только из одного потока, последовательно. Это не то, что вы нам рассказываете.

Сообщение от freeba

Самое простое решение объявить контекст как Transeit.

Я уже выше рассказал, к чему это может привести.

Добавлено через 1 минуту

Сообщение от freeba

ваш код будет примитивен.

Он будет достаточен, чтобы подтвердить утверждение. Цель не удивить сложностью и масштабом кода, а доказать поведение объекта спора.

@freeba · 02.09.2020, 11:10

Сообщение от Usaga

При использовании асинхронности, обращения к контексту идут только из одного потока, последовательно.

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

Сообщение от Usaga

Я уже выше рассказал, к чему это может привести.

Если объявить EF контекст как Transeit - он станет максимально похож на контекст linq2db. Станет быстрым и бодрым. Без полезных фишечек типа булки, ну да куда ему, убогому.

Добавлено через 2 минуты

Сообщение от Usaga

Он будет достаточен, чтобы подтвердить утверждение. Цель не удивить сложностью и масштабом кода, а доказать поведение объекта спора.

Да божешь мой. Неотличимы все(!) орм на малом количестве данных. Ну не идиоты же их разрабатывают, чтобы примитивным примером из 50 строчек им тыкали в нос и говорили - не ребят, это для крупных проектов ну никак не пойдет.

@Usaga · 02.09.2020, 11:24

Сообщение от freeba

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

Да, начаться в одном, закончиться - в другом. Это везде так. Но ПАРАЛЛЕЛЬНОГО обращения к контексту не будет.

Сообщение от freeba

Если объявить EF контекст как Transeit - он станет максимально похож на контекст linq2db. Станет быстрым и бодрым. Без полезных фишечек типа булки, ну да куда ему, убогому.

Быстрым он не станет никаким образом. Но код, полагающийся на его кеш, сломается.

Добавлено через 3 минуты

Сообщение от freeba

Да божешь мой. Неотличимы все(!) орм на малом количестве данных. Ну не идиоты же их разрабатывают, чтобы примитивным примером из 50 строчек им тыкали в нос и говорили - не ребят, это для крупных проектов ну никак не пойдет.

Я от вас требовал подтверждения ваших заявлений, которые к количеству данных отношения не имеют ровным счётом никакого. Спор не о производительности, а о повередении EF'а. Вы мне рассказываете о поведение EF'а, которого просто нет. А некоторые вещи, типа одного контекста на всё многопоточное приложение, вообще работать не могут никак. Плюс, какая-то фигня про безопасность уже пошла. Я хочу доказательства этих тезисов увидеть. Это всё легко доказывается или опровергается, без портянок кода.

Вы хоть что-то из своих слов можете доказать?

Добавлено через 9 минут

Сообщение от freeba

Если объявить EF контекст как Transeit

Кстати, можно будет ещё и на распределённую транзакцию нарваться)

@HF · 02.09.2020, 14:53

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

То что я пишу это моё понимание темы. И я нисколько не удивлюсь если где-то ошибся, и буду рад краткой информации в чём я не прав и как правильно.
1. Про ViewState. Мне кажется никто не упомянул DetectChanges. Не в курсе про контекст, но у меня всегда росли именно эти данные. Чем больше связей и изменений, тем больше "жесть" в памяти. Я даже не понимаю что там в контексте может вырасти.

2. Про мультипотоки. Помоему тут просто недопонимание или остутствие чёткого кода. Потому что да, проблемы всегда были, но нужно понимать их причину. Я сталкивался с очевидной ситуацией - блокировка конкретной сущности, которую я пытался в нескольких местах изменить. Ну это и понятно. Этот же DetectChanges и проверяет версионности.
Но на картинке выше, например, я считаю что там ошибка вообще связана с созданием контекста. Он так и говорит что OnModelCreating. Или уж не знаю почему ошибка в создании? Он же не должен его создавать снова, а использовать существующий.

3. Лично для себя давно не могу решить проблему блокировки. Вы тут такие спецы собрались, и даже мимоходом затрагивали эту тему. Вопрос простой: как сделать блокировку, которую я бы смог сделать через SQL запрос с командой "SET TRANSACTION ISOLATION LEVEL" ? Разве EF транзакция это тоже самое? Помоему он умеет это только в своём контексте это делать.
Ситуация простая: два клиента хотят изменить таблицу Users. Как мне заблокировать эту таблицу/запись? Если бы у меня был SP я бы написал команду (выше) и был бы уверен что паралельно никто не смог ничего писать. А в EF такого я не видел.

@Usaga · 02.09.2020, 16:13

Сообщение от HF

1. Про ViewState. Мне кажется никто не упомянул DetectChanges. Не в курсе про контекст, но у меня всегда росли именно эти данные. Чем больше связей и изменений, тем больше "жесть" в памяти. Я даже не понимаю что там в контексте может вырасти.

Я упоминал этот момент. Этот механизм называется Change Tracking и работает он благодаря кешу контекста. Все сущности, которые проходят через контекст, попадают в этот кеш навсегда. Т.е. кеш не очищаемый. Когда вы вызываете SaveChanges() (и при некоторых других условиях) EF начинает перебирать сущности в этом кеше и искать, что изменилось. И чем больше сущностей в этом кеше, тем дольше этот процесс. В купе с этим кешем работает и другая плюха EF'а: Identity Map. При материализации сущности оно пытается найти эту сущность в кеше и обновить именно ещё, а не создать новую. Плюс, если в кеше есть связанные сущности, которые вы даже не запрашивали (методом Include) Identity Map вам воткнёт ссылки на них в сущность.

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

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

Сообщение от HF

2. Про мультипотоки. Помоему тут просто недопонимание или остутствие чёткого кода. Потому что да, проблемы всегда были, но нужно понимать их причину. Я сталкивался с очевидной ситуацией - блокировка конкретной сущности, которую я пытался в нескольких местах изменить. Ну это и понятно. Этот же DetectChanges и проверяет версионности.
Но на картинке выше, например, я считаю что там ошибка вообще связана с созданием контекста. Он так и говорит что OnModelCreating. Или уж не знаю почему ошибка в создании? Он же не должен его создавать снова, а использовать существующий.

Блокировка записи происходит на уровне СУБД, а не EF'а. Он вообще не знает ничего про параллельные обращения к одним и тем же данным. Максимум, можно к сущности добавить Concurrency Token, чтобы EF кидался исключениями, если изменяемая запись в базе уже кем-то изменена. А исключение, которое я на скрине привёл происходит потому, что кеш контекста у EF'а не потокобезопасный и объект подключения к базе один. Он не может и не будет параллельные запросы выполнять. И это не EF'а особенность, а самого ADO.NET, который этим EF'ом используется. Проверить легко:

При этом, если одну из тасок закомментировать, то всё отрабатывает. Поэтому всякие заявления о том, что EF, якобы, может одним контекстом параллельно запросы выполнять - бред. Кто не верит, может сам проверить. И в коде контекста даже своими глазами посмотреть, что там ОДИН объект подключения.

Сообщение от HF

3. Лично для себя давно не могу решить проблему блокировки. Вы тут такие спецы собрались, и даже мимоходом затрагивали эту тему. Вопрос простой: как сделать блокировку, которую я бы смог сделать через SQL запрос с командой "SET TRANSACTION ISOLATION LEVEL" ? Разве EF транзакция это тоже самое? Помоему он умеет это только в своём контексте это делать.
Ситуация простая: два клиента хотят изменить таблицу Users. Как мне заблокировать эту таблицу/запись? Если бы у меня был SP я бы написал команду (выше) и был бы уверен что паралельно никто не смог ничего писать. А в EF такого я не видел.

У EF нет никаких "своих" транзакций. DbContext.Database.BeginTransaction() передаётся в ADO.NET при открытии подключения. А TransactionScope вообще висит в статической (но ThreadStatic) глобальной переменной, которую ADO.NET само аттачик, если там не null. А то, что вы имеете в виду (транзакция в SaveChanges) - так он просто обычную транзакцию создаёт перед исполением этого метода, а потом коммитит.

А про блокировку таблицы\записи вопрос общий. Тут больше конкретики нужно. Либо вам оптимистичная блокировка, либо блокировка на уровне бизнес-логики.

@MsGuns · 02.09.2020, 20:20

Сообщение от HF

Ситуация простая: два клиента хотят изменить таблицу Users. Как мне заблокировать эту таблицу/запись?

Кхм.. Заблокировать от кого ? Как Вы определяете, - у кого толще и длиннее или "кто первый встал - того и тапки" ?
Сервер сам прекрасно умеет блокировать что нужно и как нужно. Встревать в этот механизм нужно в крайних случаях и крайне осторожно. Надеюсь, речь не о дедлоках идет ?

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

Добавлено через 8 минут
Кстати, по поводу правки в таблице User.
Что это у Вас за система, в которой любой юзер может шалить со всей таблицей юзеров ?
Есть правило: юзер может только менять и только свои данные.
Для того, чтобы манагить всех юзеров, существует админ.

А если некий user noname в браузере открыл два окна и с обоих хочет покрыжить сам себя, так на здоровье - для каждого окна будет соблюден один и тот же сценарий и его данные изменятся 2 (два) раза.
Ну хочет чувак выстрелить себе в висок два раза - зачем ему отказывать в этом удовольствии ?

@HF · 02.09.2020, 21:34

Сообщение от Usaga

Я упоминал этот момент. Этот механизм называется Change Tracking и работает он благодаря кешу контекста. Все сущности, которые проходят через контекст, попадают в этот кеш навсегда.

1. Я в курсе. Именно это я и имел ввиду. Но вы называли это словом "кэш", поэтому не факт что именно о нём была речь. Значит мы с вами говорим об одном и том же.

Сообщение от Usaga

Проверить легко:

2. надо погонять пример. Интересно. Но я такое не использовал и не стал бы. Вообще меня чуток подбешивает современное программирование и бесконечный async.

Поэтому я бы не стал вообще в БД "асинхронно" что-то писать.

Сообщение от Usaga

У EF нет никаких "своих" транзакций. DbContext.Database.BeginTransaction() передаётся в ADO.NET при открытии подключения. А TransactionScope вообще висит в статической (но ThreadStatic) глобальной переменной, которую ADO.NET само аттачик, если там не null.

3. Наверное это и есть тот нужный мне ответ.
Но теперь я хочу доказательств, объяснений - где сказано что TransactionScope аттачится в ADO? Ведь TransactionScope не связан с БД и используется сам по себе.
Нашёл интересную ссылку. И правда, оказывается, транзакции по разному можно "готовить".
https://docs.microsoft.com/ru-... ansactions
буду читать, размышлять...

Добавлено через 4 минуты

Сообщение от MsGuns

Кстати, по поводу правки в таблице User.

Конечно это абстрактный пример.
Ну пусть это будет таблица продажи домов. Нужно продать домик - выставить в записи имя покупателя и время продажи. И есть несколько клиентов которые одновременно хотят купить эту квартирку. Как залочить запись от записи остальных на время записи первого "живчика"? Дальшейшие записи, будем считать, не будут происходить, так как система будет уже считывать значение в БД о имени и времени.

@MsGuns · 03.09.2020, 00:39

Сообщение от HF

Ну пусть это будет таблица продажи домов. Нужно продать домик - выставить в записи имя покупателя и время продажи. И есть несколько клиентов которые одновременно хотят купить эту квартирку. Как залочить запись от записи остальных на время записи первого "живчика"?

С помощью флажка "зарезервировано". Действует на дефаултный период. По истечении, если не оплачено, флажок сбрасывается. Все просто

Добавлено через 2 часа 16 минут
У меня недавно был разговор за пивком с одним хорошим человеком. Он не программер, он диллер в бизнесе недвижимости.
Так вот у них такая система.
Сайт продажи-покупки недвижимости.
Покупатель видит "дом" и делает заявку. При этом ему выдается сообщение типа "свяжитесь с агентом по телефону x.
(Там, конечно, не так просто, все через смс-ки и коды как обычно в таких случаях).
Т.е. "дом" не продается и даже не резервируется. На него собирается база потенциальных покупателей.
Это круто, т.к. чел делает заявку, но "дом" не перестает быть доступным для других. И если он потянет кота за хвост, то "дом" может быть продан другому покупателю. Когда сделка состоится, "дом" уходит из базы, а всем остальным приходит оповещение с извинениями

Т.е. в базе есть учет заявок. Так же работает и система покупок, но уже там конкурируют риэлторы

@Usaga · 03.09.2020, 07:31

Сообщение от HF

1. Я в курсе. Именно это я и имел ввиду. Но вы называли это словом "кэш", поэтому не факт что именно о нём была речь. Значит мы с вами говорим об одном и том же.

Словом "кеш" я назвал именно кеш, а не Change Tracking.

Сообщение от HF

2. надо погонять пример. Интересно. Но я такое не использовал и не стал бы. Вообще меня чуток подбешивает современное программирование и бесконечный async. Поэтому я бы не стал вообще в БД "асинхронно" что-то писать.

На самом деле асинхронность не бесплатна. И если у вас не какой-то high load проект, где пользу асинхронности ещё надо доказать, то использовать асинхронность я не вижу смысла. В вебных проектах мы async не используем. В десктопе другое дело.

Сообщение от HF

3. Наверное это и есть тот нужный мне ответ.
Но теперь я хочу доказательств, объяснений - где сказано что TransactionScope аттачится в ADO? Ведь TransactionScope не связан с БД и используется сам по себе.
Нашёл интересную ссылку. И правда, оказывается, транзакции по разному можно "готовить".
https://docs.microsoft.com/ru-... ansactions
буду читать, размышлять...

За этим далеко ходить не надо. Есть официальная документация. И можно сделать простейший пример:

TransactionScope работает:

Кликните здесь для просмотра всего текста

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
using System;
using System.Data.SqlClient;
using System.Transactions;
 
namespace ConsoleApp3
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var conn = new SqlConnection("server=localhost;database=AdventureWorks2017;integrated security=true"))
            {
                using (var tran = new TransactionScope())
                {
                    conn.Open();
 
                    using (var cmd = new SqlCommand("select count(1) from test", conn))
                    {
                        var count = (int)cmd.ExecuteScalar();
                        Console.WriteLine(count); // Проверяем количество записей
                    }
 
                    using (var cmd = new SqlCommand("insert into test (dob) values ('2010-01-01')", conn))
                    {
                        cmd.ExecuteNonQuery();
                    }
 
                    // Не комитим, транзакция откатится
                    //tran.Complete();
                }
            }
 
            using (var conn = new SqlConnection("server=localhost;database=AdventureWorks2017;integrated security=true"))
            {
                conn.Open();
 
                using (var cmd = new SqlCommand("select count(1) from test", conn))
                {
                    var count = (int)cmd.ExecuteScalar();
                    Console.WriteLine(count); // Видим тоже количество, что и до вставки
                }
            }
            Console.ReadKey();
        }
    }
}

А тут можно убедиться, что TransactionScope аттачится к подключению только во время открытия подключения к базе:

Кликните здесь для просмотра всего текста

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
using System;
using System.Data.SqlClient;
using System.Transactions;
 
namespace ConsoleApp3
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var conn = new SqlConnection("server=localhost;database=AdventureWorks2017;integrated security=true"))
            {
                conn.Open();
 
                using (var tran = new TransactionScope())
                {
                    using (var cmd = new SqlCommand("select count(1) from test", conn))
                    {
                        var count = (int)cmd.ExecuteScalar();
                        Console.WriteLine(count); // Проверяем количество записей
                    }
 
                    using (var cmd = new SqlCommand("insert into test (dob) values ('2010-01-01')", conn))
                    {
                        cmd.ExecuteNonQuery();
                    }
 
                    // Не комитим, транзакция откатится
                    //tran.Complete();
                }
            }
 
            using (var conn = new SqlConnection("server=localhost;database=AdventureWorks2017;integrated security=true"))
            {
                conn.Open();
 
                using (var cmd = new SqlCommand("select count(1) from test", conn))
                {
                    var count = (int)cmd.ExecuteScalar();
                    Console.WriteLine(count); // Видим, что записей стало больше
                }
            }
            Console.ReadKey();
        }
    }
}

Сообщение от HF

Ну пусть это будет таблица продажи домов. Нужно продать домик - выставить в записи имя покупателя и время продажи. И есть несколько клиентов которые одновременно хотят купить эту квартирку. Как залочить запись от записи остальных на время записи первого "живчика"? Дальшейшие записи, будем считать, не будут происходить, так как система будет уже считывать значение в БД о имени и времени.

Это делается с помощью отдельной таблицы "Продажи" (или иным названием). Вы ничего не блокируете и ничего не проверяете. Просто открываете транзакцию и молча вставляете запись о резервировании дома. А потом проверяете количество клиентов, которые зарезервировали этот дом. Если их больше одного, то откатываете транзакцию и кричите пользователю, что он идёт лесом. Всё. Ну или уникальный индекс на поле внешнего ключа на таблицу "Дом". Там и проверка не понадобится отдельная, запись или вставится или вы исключение получите.

@MsGuns · 04.09.2020, 12:49

Сообщение от Usaga

Это делается с помощью отдельной таблицы "Продажи" (или иным названием). Вы ничего не блокируете и ничего не проверяете. Просто открываете транзакцию и молча вставляете запись о резервировании дома. А потом проверяете количество клиентов, которые зарезервировали этот дом. Если их больше одного, то откатываете транзакцию и кричите пользователю, что он идёт лесом. Всё.

Отаке ! Т.е. послали в маркет фургон, забили его всяким товаром, а когда фургон приехал, взяли из него французскую булочку для кофе и отправили его назад в Маркет

Если все решается гораздо проще - флажком "зарезервировано".

@Usaga · 04.09.2020, 12:56

MsGuns, ну, это два разных подхода, на самом деле. Флажок не сообщает никакой информации о том, кто зарезервировал. А отдельная таблица "Бронь" или "Резервирование" позволяет не только заразервировать дом, но и дополнительную информацию сохранить. К примеру, время, когда клиент собрался прийти на смотр дома, ID клиента, ID продавца. Иными словами я посчитал, что резервирование - сущность полноценная, а не атрибут дома или его состояние (флажок).

Добавлено через 2 минуты
Ну и флажок о резервировании... Это же внешнее состояние, скажем так. Этот флажок не является атрибутом сущности Дом. Не является его частью. Некорректно этот флажок в Дом добавлять.

@MsGuns · 04.09.2020, 14:15

Usaga,
Во-первых, к "флажку" можно добавить и "подробности" в отдельной таблице - все как Вы сказали.
Во-вторых, эти "подробности" относятся к сущности "Дом" так же "близко", как и флажок.

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

Так что "некорректность" флажка (1 байт) в сущности "Дом" сомнительна, а значит - флажок корректен и уместен.

Добавлено через 4 минуты
Даже если строго следовать "правилам приличия" и не совать "флажок" в сущность "Дом", а просто проверять наличие соответствующей записи в уловном "журнале продаж", то согласитесь, что проще проверить наличие такой записи, чем ломиться продавать "Дом", получить исключение и потом радостно его обрабатывать на клиенте, загромождая код непрозрачной логикой.

Добавлено через 1 минуту
При этом, безусловно, и проверка, и "продажа" должны быть выполнены в контексте одной транзакции

Новые блоги и статьи Все статьи Все блоги /
Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.
Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .

@MyCyberMan 2 / 2 / 1 Регистрация: 09.02.2020 Сообщений: 477

	Актуальность Entity Framework 6 26.08.2020, 01:34. Показов 7019. Ответов 71 Метки entity framework, orm (Все метки) Подскажите, пожалуйста, востребован ли сейчас Entity Farmework 6 или есть более удобные средства для работы с БД? 0

@HF 1317 / 897 / 200 Регистрация: 09.09.2011 Сообщений: 2,692 Записей в блоге: 2
	02.09.2020, 14:53
	Хотелось бы тоже вклиниться, но только чтобы заполнить некоторую недосказанность в ваших рассуждениях и своих знаниях одновременно. То что я пишу это моё понимание темы. И я нисколько не удивлюсь если где-то ошибся, и буду рад краткой информации в чём я не прав и как правильно. 1. Про ViewState. Мне кажется никто не упомянул DetectChanges. Не в курсе про контекст, но у меня всегда росли именно эти данные. Чем больше связей и изменений, тем больше "жесть" в памяти. Я даже не понимаю что там в контексте может вырасти. 2. Про мультипотоки. Помоему тут просто недопонимание или остутствие чёткого кода. Потому что да, проблемы всегда были, но нужно понимать их причину. Я сталкивался с очевидной ситуацией - блокировка конкретной сущности, которую я пытался в нескольких местах изменить. Ну это и понятно. Этот же DetectChanges и проверяет версионности. Но на картинке выше, например, я считаю что там ошибка вообще связана с созданием контекста. Он так и говорит что OnModelCreating. Или уж не знаю почему ошибка в создании? Он же не должен его создавать снова, а использовать существующий. 3. Лично для себя давно не могу решить проблему блокировки. Вы тут такие спецы собрались, и даже мимоходом затрагивали эту тему. Вопрос простой: как сделать блокировку, которую я бы смог сделать через SQL запрос с командой "SET TRANSACTION ISOLATION LEVEL" ? Разве EF транзакция это тоже самое? Помоему он умеет это только в своём контексте это делать. Ситуация простая: два клиента хотят изменить таблицу Users. Как мне заблокировать эту таблицу/запись? Если бы у меня был SP я бы написал команду (выше) и был бы уверен что паралельно никто не смог ничего писать. А в EF такого я не видел. 2

@Usaga 14315 / 9401 / 1355 Регистрация: 21.01.2016 Сообщений: 35,461
	04.09.2020, 12:56
	MsGuns, ну, это два разных подхода, на самом деле. Флажок не сообщает никакой информации о том, кто зарезервировал. А отдельная таблица "Бронь" или "Резервирование" позволяет не только заразервировать дом, но и дополнительную информацию сохранить. К примеру, время, когда клиент собрался прийти на смотр дома, ID клиента, ID продавца. Иными словами я посчитал, что резервирование - сущность полноценная, а не атрибут дома или его состояние (флажок). Добавлено через 2 минуты Ну и флажок о резервировании... Это же внешнее состояние, скажем так. Этот флажок не является атрибутом сущности Дом. Не является его частью. Некорректно этот флажок в Дом добавлять. 0

@MsGuns 1497 / 1238 / 245 Регистрация: 04.04.2011 Сообщений: 4,363
	04.09.2020, 14:15
	Usaga, Во-первых, к "флажку" можно добавить и "подробности" в отдельной таблице - все как Вы сказали. Во-вторых, эти "подробности" относятся к сущности "Дом" так же "близко", как и флажок. Ну а по сути, не вижу смысла пытаться выполнить транзакцию (пр этом изменения могут делаться в нескольких таблицах), тем самым загружая сервер лишней работой, если можно просто сделать проверку. Мы ж ведь знаем оба, что сервер конкурентные транзакции выполнит строго последовательно, и, следовательно, "Дом" второй раз продан не будет Так что "некорректность" флажка (1 байт) в сущности "Дом" сомнительна, а значит - флажок корректен и уместен. Добавлено через 4 минуты Даже если строго следовать "правилам приличия" и не совать "флажок" в сущность "Дом", а просто проверять наличие соответствующей записи в уловном "журнале продаж", то согласитесь, что проще проверить наличие такой записи, чем ломиться продавать "Дом", получить исключение и потом радостно его обрабатывать на клиенте, загромождая код непрозрачной логикой. Добавлено через 1 минуту При этом, безусловно, и проверка, и "продажа" должны быть выполнены в контексте одной транзакции 0