Является платформа Объекта ADO.NET (с ASP.NET MVC v2) жизнеспособным вариантом при записи пользовательских и постоянно обновляемых веб-сайтов?

Я был использую entity framework (V1.0) около года в моем текущем проекте. У нас есть сотни таблиц, все они добавлены в edmx. Проблемы, с которыми мы сталкиваемся (хотя не уверен, решит ли новая структура сущностей эти проблемы)

1. Когда вы привыкли к VS.net IDE, вы будет использоваться для перетаскивания операции из вашей IDE. В проблема в том, что когда ваши хосты edmx Сотни таблиц, IDE действительно тормозит и вам придется ждать 3-4 минут до того, как он станет отзывчивым

2. При таком большом количестве таблиц любое редактирование вас делать на edmx долго.

3. Когда вы собираетесь использовать версию контроль, сравнение 10000 строк XML - это довольно болезненно. Подумайте о слиянии 2 ветви, каждая из которых имеет 10000 строк edmx, таблицы, новая ассоциация между таблицами, удаленные ассоциации и иду туда и обратно, сравнивая xmls. Вам понадобится хороший xml инструмент сравнения, если вы серьезно о слиянии 2-х больших файлов edmx

4. По соображениям производительности нам пришлось сделайте csdl, msl и ssdl как встроенные ресурсы

5. Ваш edmx должен быть синхронизирован с вашей БД все время или в по крайней мере, когда вы пытаетесь обновить edmx, он попытается синхронизироваться и может выдают какие-то непонятные ошибки, если они не синхронизированы.

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

Что мы сделали / я мог бы рассмотреть в будущем при использовании EF

1. Используйте несколько edmx, используя 1 edmx для таблиц, логически сгруппированных / связанных вместе.Помните о том, что если вы сделаете это, каждый edmx должен жить в собственном пространстве имен. если ты попробуйте добавить 2 связанные таблицы (скажем, лицо и адрес) на 2 edmx в то же пространство имен, вы получите ошибка компилятора, указывающая, что отношения по внешнему ключу уже есть определенный. (Совет: создайте папку и создайте edmx в этой папке. Если вы попытаетесь изменить пространство имен в edmx без папки, он не сохраняет должным образом пространство имен в следующий раз, когда вы открыть / отредактировать)

    меньше таблиц в edmx => менее тяжелые
   контейнер => хорошо
   

   меньше таблиц в edmx => проще объединить при объединении 2-х веток

2. Имейте в виду, что объект контекст не является потокобезопасным

3. Ваш репозиторий (или любой другой DAO, который вы используете) должен нести ответственность за создание и удаление контейнера, который он создает. Использование фреймворков DI, особенно в веб-приложениях, усложняет нам задачу. Веб-запросы обслуживаются из пула потоков, и контейнер не был должным образом удален после обслуживания веб-запроса, поскольку сам поток не был удален. Контейнер использовался повторно (при повторном использовании потока) и создавал множество проблем с параллелизмом

4. Не доверяйте своей VS IDE. Получить хороший XML-редактор и знаете, как редактировать edmx файл (хотя вам и не нужно редактировать конструктор). Пачкайте руки

5. ВСЕГДА ВСЕГДА ВСЕГДА (просто не могу этого подчеркнуть) запустите Профилировщик SQL (я имею в виду каждый и каждый шаг вашего кода), когда вы выполнять ваши запросы.Такой же сложный, как запрос может выглядеть, вы будете удивлен, узнав, сколько раз ты ударил пример БД: (извините, не могу получить код в нужном формате, может кто-нибудь его форматирует?)

    var myOrders = from t в context.Table, где t.CustomerID = 123
   

   выберите t; // запрос выше еще не выполнено

   if (myOrders.Count> 0) // запрос БД к find count { var firstOrder = myOrders.First () // запрос к БД для получения первый результат }

   Лучший подход

   // запрос материализован, всего 1 обращение к БД, поскольку мы используем ToList () var myOrders = (от t в Context.tables где t.customerID = 123 выберите t) .ToList ();

    if (myOrders.Count> 0) // нет попадания в БД
   {
   //сделай что-нибудь
   var myOrder = myOrders [0]; // нет попадания в БД
   }
   

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

7. Я забыл скомпилированные запросы? Смотреть здесь , чтобы получить больше вкусностей

8. При получении тысяч строк назад из вашей БД, убедитесь, что вы используете IQueryable и отсоедините objectContext , чтобы вы не заканчивается память

Обновление:

Джули Лерман решает ту же проблему с помощью аналогичного решения . Ее сообщение также указывает на работу Уорда по работе с огромным количеством таблиц