Советы по переходу с XPO на LINQ to SQL - PullRequest
Новая
       14

Советы по переходу с XPO на LINQ to SQL

3 голосов
/ 10 июля 2009

Я давний пользователь библиотеки DevExpress XPO. У него много замечательных функций, но есть несколько слабых мест:

  1. При сохранении существующего объекта все свойства отправляются в запросе на обновление; изменения отслеживаются для каждого объекта, а не для каждого свойства.
  2. Оптимистическая блокировка выполняется для каждого объекта, а не для каждого столбца.
  3. Когда возникает исключение оптимистической блокировки, не предоставляется контекст, описывающий природу конфликта; Ваш единственный реальный ответ - не выполнить операцию или воспроизвести ее и повторить попытку.
  4. Поддержка LINQ для XPQuery очень слабая (по крайней мере в 8.1, которую мы используем). Таким образом, вам часто приходится использовать XPView, который не является безопасным для типов, или XPCollection, который может возвращать столбцы, которые вам не обязательно нужны.

После прочтения о том, как LINQ to SQL реализует оптимизацию блокировки и обработки конфликтов обновления, я был продан! Мне нравится, как он реализует оптимистическую блокировку на уровне столбцов и не нуждается в добавлении столбца в таблицу. Возможность проверять и обрабатывать точную природу конфликтов - это прекрасно. А тот факт, что они отслеживают изменения по столбцам, должен значительно повысить эффективность запросов на обновление.

Конечно, я еще не использовал LINQ to SQL в реальных приложениях, поэтому я не знаю, насколько это реально. Кроме того, мне неясно, есть ли у него аналоги некоторых функций, которыми мы наслаждаемся в XPO, таких как:

  1. Автоматические обновления схемы (мы верим, что структура базы данных управляет структурой базы данных, а не наоборот, и это значительно упрощает развертывание программного обеспечения)
  2. Два варианта реализации наследования (отношения с одной и той же таблицей или с таблицей один-к-одному)
  3. Поддержка хранения в памяти (хотя я полагаю, что мы могли бы заменить LINQ на Objects в наших модульных тестах)
  4. Настройка провайдера хранилища (что позволило нам добавить поддержку NOLOCK в наши запросы XPO)

Мы собираемся выполнить предварительную частичную миграцию, в которой мы временно будем использовать два ORM для разных частей нашего кода. Кто-нибудь из вас имел реальный опыт работы с XPO и LINQ to SQL? Как они сравниваются на практике? В частности, вам известны какие-либо функции, которых нет в LINQ to SQL, которые могли бы создать проблемы при переносе кода?

О, и я должен даже заботиться о LINQ to Entities? Это выглядит намного сложнее, чем все, что нам нужно.

Ответы [ 2 ]

2 голосов
/ 16 декабря 2009

Мне грустно, что я не получил никаких ответов от сообщества, но вот мои мысли до сих пор. У меня была возможность опробовать LINQ to SQL и ADO.NET Entity Framework на разных проектах, и я чувствую, что ADO.NET Entity Framework лучше удовлетворит наши потребности. Что касается особенностей XPO, которые я надеялся сохранить:

  1. Автоматические обновления схемы должны произойти после того, как мы конвертируем. Это небольшое раздражение, но есть несколько преимуществ для поддержания этого отдельно.
  2. ADO.NET Entity Framework имеет множество параметров отображения данных; различные модели наследования, по-видимому, поддерживаются.
  3. Что касается хранения в памяти, я все еще не уверен, насколько хорошо это поддерживается. Похоже, что существует поставщик SQLite ADO.NET, совместимый с Entity Framework, и SQLite может выполнять хранение в памяти, поэтому теоретически модульные тесты могут использовать другую строку подключения, определяющую базу данных в памяти. Надеюсь, это так просто; в противном случае написание модульных тестов будет довольно сложным без большой работы (абстрагирование интерфейса репозитория и т. д.).
  4. Я еще не изучал настройку провайдера. Я пытался спроектировать систему таким образом, чтобы у нас не было такого большого количества данных, которые делятся между службами, как раньше, поэтому, возможно, нам не понадобятся все те операторы WITH (NO LOCK), которые мне были нужны в предыдущих системах. Или, возможно, SQL Server 2008 улучшил свои механизмы блокировки, чтобы мы не сталкивались с такими же проблемами блокировки.
0 голосов
/ 12 марта 2010

Итак, вы перенесли свое приложение из XPO в Linq2Sql? Я также играл с XPO как часть XAF, честно говоря, я предпочитаю Linq2Sql / EF XPO, но так как он тесно связан с XAF, у меня нет другого выбора. Мы собираемся использовать XAF для ускорения реализации пользовательского интерфейса нашего продукта, я думаю, что XAF выполняет свою работу достаточно хорошо, но я действительно беспокоюсь о XPO.

Спасибо

...