Советы по миграции из XPO в LINQ to SQL

Question

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

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

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

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

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

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

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

Answer 1

Мне грустно, что я не получил ответов от сообщества, но вот мои мысли до сих пор. У меня была возможность попробовать 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 улучшил свои механизмы блокировки, так что мы не столкнемся с теми же проблемами блокировки.

Answer 2

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

Спасибо,