Поддерживает ли Linq to SQL или Linq to Entities 4.0 тип иерархии?

Question

Есть ли способ использовать linq to SQL / Entities 4.0 для работы с типом иерархии?

Answer 1

Ни одно из семейства ORM Microsoft не может использовать пользовательские типы CLR (включая встроенные hierarchyid и геопространственные типы) в качестве типов столбцов.

Если вы используете их в своей базе данных, у вас есть два обходных пути:

1. Добавить вычисляемый столбец в таблицу иерархии с выражением CAST(hid AS varbinary892)). Вам нужно убедиться, что вы включаете этот столбец в каждый запрос (включая хранимые процедуры), который используется Linq. Затем добавьте этот столбец к отображению сущности.

   На этом этапе вы можете расширить частичный класс сущности, добавив «настоящий» столбец hierarchyid в качестве собственного свойства, добавив ссылку на Microsoft.SqlServerTypes и используя классы BinaryReader / BinaryWriter для преобразования Данные BLOB в / из SqlHierarchyId.

   Обратите внимание, что вы не можете писать запросы Linq к этому столбцу . Вы просто получите сообщение об ошибке «не поддерживается перевод», если попытаетесь. Так что имейте в виду, что это ограниченный обходной путь.

2. Другой вариант, который я обычно предпочитаю, это вообще не использовать столбец hierarchyid изнутри L2S / EF. Добавьте отдельно проиндексированный суррогатный ключ auto-inc в таблицу иерархии и обработайте hierarchyid как подробность реализации. Используйте пользовательские функции и представления для реализации иерархических запросов, для которых в качестве параметра требуется только суррогатный идентификатор.

   Это звучит как боль, но это не так уж и плохо, если вы работаете таким образом с самого начала. До того, как Microsoft представила тип hierarchyid, я использовал адаптацию материализованной иерархии путей Денниса Форбса, которая основывалась на списке смежности и поддерживала путь как своего рода денормализацию. hierarchyid делает это намного проще.

   К сожалению, у меня нет полного рабочего примера всего, что вам нужно сделать, чтобы поддерживать правильные ассоциации между hierarchyid и списком смежности, но если вы прочитаете статью Денниса , это должно быть хорошо Начните. Не реализуйте материализованный путь, используйте вместо него hierarchyid, но прочитайте разделы о реализации самостоятельных иерархий с триггерами.

   Если Microsoft когда-либо реализует поддержку hierarchyid в своих ORM, было бы легко удалить список смежности и переключиться исключительно на решение, основанное на hierarchyid. Но поскольку для управления иерархиями, основанными на hierarchyid, требуется множество хранимых процедур для поддержки в любом случае (так как вы не получаете «автоматические» идентификаторы), вы должны освоиться с написанием большого количества пользовательских функций SQL и сохраненных Процедурные абстракции вокруг иерархических запросов.

Answer 2

Мы используем решение, аналогичное Aaronaught, с Linq to SQL.

Мы создали вычисляемые столбцы

    TreeId.ToString()

для текущего столбца иерархии и

    [TreeId].[GetAncestor](1).ToString()

для прямых родителей.

Мы также создали представление, которое исключает иерархию-столбец, и перетащили это представление на Dbml-диаграмму и настроили связи с ссылочными таблицами.

Большинство функций иерархии должно быть в форме хранимых процедур.

Answer 3

Одним словом, нет. Во всяком случае, не напрямую. Вы можете обойти это, как и геопространственные типы . Я не пробовал.