Я давний пользователь библиотеки DevExpress XPO. У него много замечательных функций, но есть и недостатки:
- При сохранении существующего объекта все свойства отправляются в запросе на обновление; изменения отслеживаются для каждого объекта, а не для каждого свойства.
- Оптимистическая блокировка выполняется для каждого объекта, а не для каждого столбца.
- Когда возникает исключение оптимистической блокировки, контекст, описывающий природу конфликта, не предоставляется; ваша единственная реальная реакция — провалить операцию или воспроизвести ее и повторить попытку в цикле.
- Поддержка LINQ для XPQuery очень слаба (по крайней мере, в версии 8.1, которую мы используем). Таким образом, вы часто вынуждены использовать XPView, который не является типобезопасным, или XPCollection, который может возвращать столбцы, которые вам не обязательно нужны.
Прочитав о том, как LINQ to SQL реализует оптимизирующую блокировку и обработку конфликтов обновлений, я был поражен! Мне нравится, как он реализует оптимистическую блокировку на уровне столбца и не требует добавления столбца в таблицу. Возможность исследовать и обрабатывать точную природу конфликтов — это здорово. И тот факт, что они отслеживают изменения для каждого столбца, должен сделать его запросы на обновление намного более эффективными.
Конечно, я еще не использовал LINQ to SQL в реальных приложениях, поэтому не знаю, можно ли сравнить его в реальности. Кроме того, мне неясно, есть ли у него аналоги некоторых функций, которыми мы наслаждаемся в XPO, таких как:
- Автоматические обновления схемы (мы верим, что структура базы данных определяется объектным дизайном, а не наоборот, и это значительно упрощает развертывание программного обеспечения)
- Два варианта реализации наследования (отношения одной таблицы или таблицы "один к одному").
- Поддержка хранилища в памяти (хотя я полагаю, что мы могли бы заменить LINQ to Objects в наших модульных тестах)
- Настройка поставщика хранилища (что позволило нам добавить поддержку NOLOCK в наши запросы XPO)
Мы собираемся выполнить пробную частичную миграцию, в которой временно будем использовать две ORM для разных частей нашего кода. Был ли у кого-нибудь из вас реальный опыт работы как с XPO, так и с LINQ to SQL? Как они соотносятся на практике? В частности, знаете ли вы о каких-либо функциях, отсутствующих в LINQ to SQL, которые могли бы создать проблемы при миграции кода?
О, и должен ли я вообще заботиться о LINQ to Entities? Это выглядит намного сложнее, чем все, что нам нужно.
