Entity Framework 4.1 для большого количества таблиц (715)

Я разрабатываю уровень доступа к данным для базы данных с более чем 700 таблицами. Я создал модель, включая все таблицы, которые создали огромную модель. Затем я сменил модель на использование DBContext с 4.1, который, казалось, улучшил его компиляцию и работу. Дизайнер не работал вообще.

Затем я создал тестовое приложение, которое просто добавило две таблицы в таблицу, но процессор пошел на 100% в методе db.SaveChanges. Будучи черным ящиком, было трудно определить, что пошло не так.

Итак, мои вопросы

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

Если это так, следует ли разбить модель на логические области. Я заметил, что вы не можете иметь одну и ту же таблицу sql в нескольких моделях.

Я читал, что подход только кода лучше всего в этих больших случаях. Что это такое.

Любое руководство будет действительно оценено

Спасибо

Ответ 1

Большая база данных всегда что-то особенное. Любая технология имеет некоторые плюсы и минусы при работе с большой базой данных.

Проблема, с которой вы столкнулись, скорее всего связана с построением модели. Когда вы запускаете приложение и используете материал, связанный с EF, в первый раз EF должен создать описание модели и скомпилировать ее - это самая трудоемкая операция, которую вы можете найти в EF. Сложность этой операции растет с количеством объектов в модели. После компиляции модели она используется повторно для всего жизненного цикла приложения (если вы перезапустите приложение или выгрузите домен приложения, модель должна быть скомпилирована снова). Вы можете избежать этого, предварительно скомпилировав модель. Это делается во время разработки, когда вы используете какой-либо инструмент для генерации кода из модели, и вы включаете этот код в свой проект (это нужно делать снова после каждого изменения в модели). Для моделей на основе EDMX вы можете использовать EdmGen.exe для создания представлений и для моделей на основе кода, которые вы можете использовать EF Power Tools CTP1.

EDMX (разработчик) был улучшен в VS 2010 SP1, чтобы иметь возможность работать с большими моделями, но я все же считаю, что в этом случае большой размер составляет около 100 сущностей/таблиц. В то же время вам редко нужно 715 таблиц в той же модели. Я считаю, что эти 715 таблиц действительно моделируют несколько доменов, поэтому вы можете разделить их на несколько моделей.

То же самое верно, если вы сначала используете DbContext и код. Если вы моделируете класс, считаете ли вы, что это правильный дизайн, когда класс предоставляет свойства 715? Я так не думаю, но это именно то, что выглядит ваш производный DbContext - он имеет общедоступное свойство для каждого выставленного объекта сущности (в простейшем отображении это означает одно свойство для таблицы).

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

Только код = code first = Entity framework, когда вы определяете отображение в коде без использования EDMX.

Ответ 1

Ответ 2